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(57) Abstract 



The present invention is a method and apparatus for effectuating bilateral buyer-driven commerce. The present invention allows 
prospective buyers (400) or sellers (300), for sellers conveniently to search for relevant buyer purchase offers, and for sellers potentially to 
bind a buyer to a contract based on the buyer's purchase offer. In a preferred embodiment, the apparatus of the present invention includes a 
controller (200) that receives binding purchase offers from prospective buyers. The controller makes purchase offers available to potential 
sellers and then determines if one or more sellers are willing to accept a given purchase offer. The method and apparatus of the present 
invention have applications on the Internet as well as conventional communications systems such as voice telephony- 
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CONDITIONAL PURCHASE OFFER MANAGEMENT SYSTEMS 

Field of the Invention 

The present invention relates to a method and apparatus for processing 
5 the sale of products using electronic networks to customers who have submitted an offer 
for. the purchase of such products. 

Background of the Invention 

Most systems for processing the sale of products are seller-driven, 

10 whereby the seller prices, packages and configures the product, and the buyer decides 
whether or not to accept. Traditionally, the seller must attract buyers and complete the 
sale, Thus, in a seller-driven system, the advertising cost of the transaction and the 
attendant risks that such advertising will be unsuccessful falls upon the seller. 

Typically, goods and services are sold in a retail environment using a 

15 seller-driven protocol, whereby the seller generally sets a non-negotiable price that the 
buyer may accept or reject. Other forms of commerce provide more flexibility and 
permit the exchange of offers and counteroffers. In an auction, for example, the buyer 
does not find the seller, rather the seller attracts numerous buyers who collectively 
determine the final selling price, which the seller may subsequently reject unless the 

20 item auctioned is being sold without a reserve. Other commerce systems, such as 
NASDAQ or the New York Stock Exchange (NYSE), are exchange-driven, where 
buyers and sellers are matched by offering an efficient, fair and orderly marketplace. 
Such exchange-driven systems favor neither buyers nor sellers, but simply effectuate 
communications that allow for the matching process to take place. An example of an 

25 automated exchange-driven commerce system for trading futures is disclosed in United 
States Patent Number 4,903,20 1 . 

A buyer-driven system, on the other hand, is one where the buyer 
dictates the terms of the offer and the seller decides whether or not to accept A "help 
wanted 1 * advertisement, for example, is a buyer-driven inquiry since the employer is 

30 looking to locate and buy the services of a qualified employee. The inquiry is 
advertised to a large number of potential employees, who may respond by submitting 
their resumes to the prospective employer. Generally, buyer-driven systems are more 

1 
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preferable than other systems for processing the sale of products. For example, buyer- 
driven systems provide buyers with more control over the terms and conditions of the 
purchase of a desired product. Additionally, when a large number of potential sellers 
exist, but those sellers do not have the resources to advertise globally, buyers can take 
the initiative to communicate their needs to the sellers. 

Unilateral buyer-driven systems seek to consummate contracts between 
buyers and sellers based on acceptance of an offer by performance of a designated task. 
For example, in a reward system, a "buyer" broadcasts or publishes an offer for a 
reward to anyone who completes a particular task. Thus, unilateral systems can be 
utilized only for limited types of transactions that allow for acceptance by performance. 
Bilateral buyer-driven systems, on the other hand, seek to consummate contracts 
between buyers and sellers based on mutual promises to perform. Bilateral buyer- 
driven systems, however, require buyers to invest a lot of time, money and other 
resources to locate an indefinite number of potential sellers and communicate the 
15 buyer's purchasing needs to each seller. Any benefits to the consumer with 
conventional bilateral buyer-driven systems, however, including a potentially lower 
price, are typically outweighed by the amount of time and money expended in the effort. 
In addition, buyer-driven systems impose inherent costs on sellers as well. If each 
buyer has a different set of purchasing specifications and communicates his needs using 
20 non-uniform language, sellers must pay a substantial cost to review and understand each 
individual request. Moreover, sellers are often not amenable to customizing their 
products for individual buyers. 

An example of a regularly used bilateral buyer-driven process is the 
system utilized by large organizations, such as companies or governments, who want to 
purchase significant amounts of goods or services at the lowest possible price. Initially, 
purchasers formulate a detailed written specification, typically called a "Request for 
Proposal" (RFP), setting forth the quantities and requirements of what they are looking 
to buy. Once finalized, the RFPs are then distributed to a list of known potential 
suppliers. Potential suppliers then screen the RFPs to identify those that they might be 
able to fulfill, and thereafter determine whether or not to invest the necessary time and 
effort to submit a formal binding proposal to the buyer by a deadline established in the 
RFP. Once submitted, the proposals are evaluated by the buyer, and the supplier 
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corresponding to the selected proposal is notified that it has "won" the business at the 
price quoted. 

Large organizations can take advantage of the benefits afforded by the 
RFP process because their volume buying represents a worthwhile opportunity for 
5 suppliers to compete for their business and large organizations have the resources to 
communicate their buying needs to a sufficient number of suppliers. As a result, large 
organizations can often achieve substantial unit cost savings, especially on commodities 
or commodity services (such as paper clips or long distance service) and on perishable 
items (such as airline tickets and hotel rooms). Individual consumers, however, cannot 

10 effectively participate in such bilateral buyer-driven systems because they generally do 
not have the buying power and resources of large organizations. 

As commerce seeks to utilize the inherent advantages of the Internet, 
many systems for processing the sale of products, such as malls, catalogs and auction 
houses, are being implemented on the Internet. These approaches generally seek to 

15 create better seller or exchange-driven systems whereby the sale of goods and services 
is. made more efficient. While there have been some attempts to use the Internet to 
effectuate bilateral buyer-driven transactions, those attempts have been largely 
unsuccessful. For example, buyers can post "wanted" advertising at little or no cost on 
"bulletin board" type Internet sites. Thus, consumers can essentially post their own RFP 

20 to a large number of sellers willing to sell them the exact product they are looking for. 
In practice, however, it is impractical for potential sellers to frequent the various 
"bulletin board" sites or respond to the individual RFPs which typically have diverse 
formats, conditions, terms, and language styles. In addition, sellers are deterred from 
using such a process because there is (i) no guarantee of the authenticity of the RFP, (ii) 

25 the cost of negotiating with individual consumers is often too high, and (iii) it is difficult 
to enforce any agreement (including payment guarantees) which may be reached 
between the consumer and the seller. In turn, the absence of a critical mass of sellers 
reduces the incentive for buyers to post their RFPs. 

Many industries, as well as consumers, would benefit from an effective 

30 bilateral buyer-driven system. Recently, for example, the travel industry has 
experienced explosive worldwide growth. As travel capacity continues to increase, it is 
expected that capacity will outpace projected traveler volumes, thereby reducing 
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utilization and putting pressure on pricing. In order to deal with such pricing and 
inventory challenges, many travel-related sellers have developed sophisticated revenue 
management systems (RMSs) to optimize revenue by dynamically setting the price for 
available inventory. Generally, when inventory is first added by a seller, the seller's 
5 revenue management system attempts to max.mize revenue for the inventory by 
establishing a plurality of price classes and then allocating the inventory and price 
assigned to each price class. The revenue management system thereafter continues to 
monitor the actual demand within each price class relative to forecasted demand, 
dynamically reevaluating the inventory allocation and pricing of each price class for 
10 given inventory. 

While conventional revenue management systems employ sophisticated 
tools to anticipate future travel needs, forecasting errors invariably lead to unanticipated 
excess capacity. In addition, a seller can utilize its revenue management system to 
forecast anticipated excess capacity, such as excess capacity on a given flight associated 
15 with seats that are predicted to be empty. Furthermore, unexpected external events, 
such as a price war or extreme weather conditions, can also affect a seller's excess 
capacity. Thus, in an attempt to reduce such excess capacity, sellers periodically 
reevaluate the inventory allocation and pricing. Travel -related sellers cannot simply 
discount the published prices for such unsold inventory, however, without either starting 
10 a price war or compromising their own underlying price structure (i.e., without also 
reducing its full-fare prices for full-fare travelers). Thus, there is currently no effective 
way for travel-related sellers to dispose of such excess capacity. 

Travel-related sellers recognize that there is a large source of latent 
demand associated with leisure travelers who are willing to travel at a favorable price. 
There is currently no effective way, however, for such sellers to receive an offer from a 
buyer for leisure travel at a particular price set by the buyer, below the seller's published 
price. In particular, there is ho effective way for the seller to be confident that if the 
seller accepts the buyer's offer, the buyer will travel in accordance with the offer, 
without using the information to ascertain the seller's underlying level of price 
flexibility, which, if known to a seller's competitors or buyers, could dramatically 
impact the seller's overall revenue structure. 
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Similarly, with the long distance telephone market becoming nearly 
saturated with supply, competition among long distance carriers for new business has 
increased dramatically. Although the costs associated with long distance calls have 
dropped and are expected to continue dropping dramatically in the United States and 
5 other countries as the result of increased competition, the cost of a long distance call 
remains sufficiently high to discourage many people from placing as many long 
distance calls as they would like. In addition, most callers are typically unfamiliar with 
the rate structure associated with placing calls to various geographical areas at various 
times of day. Thus, the inability to identify and control the cost of a long distance call 
10 has further contributed to the reluctance of many people to place more long distance 
calls. 

While many large customers, such as corporate customers, often have 
sufficient leverage to negotiate their long distance rates with a long distance carrier, or 
to permit carriers to bid for their account, it is impractical, given current telephone 

15 systems, for long distance providers to individually negotiate long distance rates with 
the average consumer. In addition, many large customers have accounts with a number 
of different long distance carriers, and employ "least cost routing" technology in their 
proprietary private branch exchange (PBX) switches or other customer-premises 
equipment. This technology enables them to select the most cost-effective carrier on a 

20 per-call basis using stored rate information. Again, such a cost-reduction solution is not 
available to the average consumer, who typically has only one long distance provider. 
While systems have been developed to allow consumers to identify a long distance 
carrier offering the most cost-effective published rate to complete a call, such systems 
do not facilitate real-time negotiation with individual carriers, or permit one or more 

25 telephone calls to be completed in accordance with restrictions specified by the calling 
party. 

In addition, conventional commerce systems limit the ability of resellers 
of tickets for events, such as a concert, play or sporting event, to advertise ticket 
availability and complete a ticket transaction. Currently, ticket resellers may utilize 
30 . classified advertisements, electronic bulletin boards or "chat rooms" on the Internet to 
advertise ticket availability. Such advertisements are difficult to remove from the 
public realm once the tickets are resold. Thus, a person selling a ticket may get 
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inquiries after the ticket has been sold. In addition, the buyer requires physical 
possession of the actual ticket, and delivery immediately prior to the event may be 
problematic. Furthermore, buyers and sellers of tickets possess a general distrust of 
each other. Unless a buyer is face-to-face with a ticket reseller, the buyer is typically 
unwilling to pay for tickets without some assurance of delivery. Likewise, a ticket 
reseller is typically unwilling to deliver tickets without payment in advance. 
Conventional ticket reselling systems, however, do not provide any mechanism for 
guaranteeing the authenticity of either the buyer or the seller. 

In addition to the above -described drawbacks of known commerce 
systems, sellers often require information relevant to a buyer's offer from a third party 
in order to determine whether to accept the offer. For example, potential buyers of 
artworks require that the artworks be accompanied by a trusted third party's "seal of 
approval." Such a seal would typically authenticate that the artworks are genuine, and 
also appraise their value. Similarly, potential lenders of funds require the credit history 
or a "credit score" of a potential borrower. Lenders would typically not accept such 
critical information from the potential borrower, since the borrower might try to alter 
the information to appear more credit-worthy. The credit information must come from a 
trusted third party. 

Accordingly, an offer to borrow funds, which would include borrower- 
specified conditions, such as an interest rate and loan amount, would, by itself, be 
insufficient for the lender to determine whether to accept the offer. Potential lenders 
would not be able to ascertain whether the offer was acceptable in terms of credit risk 
and credit worthiness. Thus, buyers would not be able to usefully make such offers. 
Current systems for evaluating borrower credit risks in connection with the sale of 
financial products, such as the system disclosed in United States Patent Number 
5,611,052, do not permit potential borrowers to specify desired loan conditions. In 
addition, the system disclosed in United States Patent Number 5,611,052 does not 
prevent people who do not intend to buy from inundating a seller of financial products 
with worthless loan applications. 

As apparent from the above deficiencies with conventional systems for 
processing the sale of products, a need exists for a bilateral buyer-driven system, 
capable of being utilized by individual consumers to communicate their purchasing 
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needs globally to potential sellers, which addresses the deficiencies of the prior art. A 
further need exists for a bilateral buyer-driven system which authenticates the terms and 
conditions of buyer offers. There is also a need for third party administration in such a 
bilateral buyer-driven system to resolve contract disputes between the parties, increase 
5 buyer and seller confidence in the system and establish standard protocols, formats, 
terms and language to be used in buyer-specified offers. A further need exists for a 
system that permits a seller to sell excess capacity when actual demand fails to meet 
forecasted demand. Another need exists for a buyer-driven system that permits a buyer 
to obtain products at a price set by the buyer, typically below the published price of the 
10 product. Yet another need exists for a system that permits sellers to stimulate sales of 
excess inventory or capacity, without compromising the seller's published price 
structure. Finally, there is a further need for a system that allows sellers to evaluate the 
acceptability of an offer from a buyer in light of information relevant to the offer from a 
third party. 

15 

Summary of the Invention 

A conditional purchase offer (CPO) management system for 
consummating a binding contract between a remote prospective buyer and a remote 
potential seller is disclosed, including a memory device, and a processor disposed in 

20 communication with the memory device, the processor configured to receive from the 
remote prospective buyer (a) a purchase offer containing at least one condition, and (b) 
a payment identifier for specifying a general purpose financial account from which 
funds may be paid for a purchase meeting the at least one condition, the processor 
further configured to transmit the purchase offer to a plurality of remote potential 

25 sellers, and receive from at least one of the remote potential sellers an unconditional 
acceptance of the offer. In one embodiment of the invention, the processor is further 
configured to initiate the use of the payment identifier to effect payment for the 
purchase from the buyer, and the general purpose financial account is a credit card 
account. In various embodiments of the invention, the at least one condition may be 

30 selected from the group consisting of price, quantity, delivery date, quality, geographic 
location, and anonymity. 
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A system according to another embodiment of the present invention, that 
permits the CPO management system to accept or reject a given CPO on behalf of 
certain agency-based sellers who have delegated such authority to the CPO management 
system, is disclosed, including a communications port and a processor. The 

5 communications port obtains a purchase offer for travel from a customer and receives 
one or more rules from a plurality of sellers. The purchase offer contains at least one 
customer-defined condition and each of the rules contains one or more seller-defined 
restrictions. The processor compares the purchase offer to the rules to determine 
whether the customer-defined condition satisfies each of the seller-defined restrictions 

10 of at least one of the rules. 

In one embodiment, if a CPO is accepted by more than one seller, the 
CPO management system executes a post-sell multi-bind process to permit each 
accepting seller to directly market to the customer and post-sell their product. Thus, the 
customer still selects for himself which seller acceptance to utilize, based on materials 
5 or incentives furnished by each seller. The customer is bound by the CPO management 
system, in accordance with the terms of the CPO, and is obligated to purchase the goods 
or services specified by the CPO, but the buyer may decide which seller to utilize, based 
on materials or incentives provided to the customer directly by each accepting seller. 

A CPO submitted by a customer can specify one or more preferred 
sellers. Thus, the CPO management system provides the CPO to each specified seller to 
determine if one or more of the sellers are willing to accept the CPO. In a supplemental 
embodiment, the CPO management system preferably executes an excluded seller CPO 
evaluation process to provide the CPO to the excluded sellers who may make 
counteroffers to the customer, in an attempt to obtain the business, before one of the 
specified sellers accepts the CPO. The CPO can be provided to the excluded sellers 
before, or contemporaneously with, the preferred sellers. 

A system according to another embodiment of the present invention, 
suitable for processing the sale of packages of goods and services, is disclosed, 
including a communications port and a processor. The communications port receives a 
purchase offer for a package from a customer. The purchase offer contains a 
description of each component item and a payment identifier for specifying a general- 
purpose account from which funds may be paid. The processor deconstructs the 
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package purchase offer into a plurality of component purchase offers and determines if 
each of the component purchase offers are accepted by one or more potential sellers. 
The customer is thereby bound to purchase the package if an acceptance is received for 
each of the component purchase offers. 
5 A system according to another embodiment of the present invention, 

suitable for processing purchase offers for one or more telephone calls, is disclosed, 
including a communications port and a processor. The communications port obtains a 
purchase offer from a customer for one or more telephone calls and provides the 
purchase offer to a plurality of potential carriers. The purchase offer contains at least one 
10 customer-defined condition and a payment identifier for specifying a manner in which 
funds will be paid. The processor determines if one or more of the carriers accepts the 
purchase offer and binds the customer to purchase the telephone calls if an acceptance is 
received for the purchase offer. 

A method according to another preferred embodiment of the present 
15 invention suitable for reselling event tickets includes: a potential buyer electronically 
transmitting a guaranteed purchase offer for a ticket to a central controller; the central 
controller electronically making the offer available to a plurality of potential sellers; a 
first-accepting seller transmitting an acceptance of the offer to the central controller; and 
the central controller transmitting this acceptance to the buyer along with a code to use 
20 at a venue to verify his purchase of the ticket. 

Thus, one preferred embodiment of the present invention provides 
individuals a quick and easy way to purchase a ticket from a ticket reseller, and allows 
them to avoid the traditional problems of the ticket resale market. Moreover, ticket 
resellers can sell a ticket based on a guaranteed purchase offer provided by a potential 
25 buyer. In addition, the present invention includes mechanisms which prevent fraud both 
during and after the transaction. 

Generally, according to a further embodiment of the present invention, 
that permits sellers to evaluate the acceptability of an offer from a buyer in light of 
information relevant to the offer from a third party, a central controller receives an offer 
30 signal including at least one condition signal. The offer signal defines a conditional 
purchase offer having at least one condition from a customer. The central controller 
also receives a payment identifier signal for specifying an account from which funds 
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may be paid. An informational signal relevant to the offer is received from a third 
party. The informational signal typically includes relevant information that would not 
be trusted if it came from the borrower submitting the conditional purchase offer. 

A more complete understanding of the present invention, as well as 
5 further features and advantages of the present invention, will be obtained by reference to 
the following detailed description and drawings. 

Brief Description of the Drawings 

Figure 1 illustrates a first embodiment of the present invention. 
10 Figure 2 is a block diagram showing one embodiment of the central 

controller. 

Figure 3 is a block diagram showing one embodiment of the seller 

interface. 

Figure 4 is a block diagram showing one embodiment of the buyer 

15 interface. 

Figure 5 illustrates an embodiment showing how a conditional purchase 
offer is generated. 

Figure 6 illustrates an embodiment showing the acceptance of a 
conditional purchase offer by the central controller. 
20 Figure 7 illustrates an embodiment showing the activation of a 

conditional purchase offer. 

Figure 8 illustrates one embodiment of the maintenance of active 
conditional purchase offers. 

Figure 9 illustrates an embodiment showing the seller selecting a 
25 conditional purchase offer. 

Figures 10 and 11 illustrate an embodiment showing the binding of a 
conditional purchase offer. 

Figure 12 illustrates an exemplary procedure for exchanging goods and 
payment between buyer and seller. 
30 Figure 13 illustrates an exemplary payment method. 

Figures 14 through 17 illustrate an exemplary authentication procedure 
using cryptographic protocols. 
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Figures 18 and 19 illustrate an exemplary embodiment for counteroffers 

by a seller. 

Figure 20 illustrates an embodiment showing the use of a trusted server 
and a bonding agency. 

5 Figure 21 is a schematic block diagram illustrating a conditional 

purchase offer (CPO) management system in accordance with one embodiment of the 
present invention. 

Figure 22 is a schematic block diagram of the exemplary CPO 
management central server of Figure 21 . 
10 Figure 23 is a schematic block diagram of the exemplary secured airline 

server of Figure 21. 

Figure 24 is a schematic block diagram of the exemplary central 
reservation system of Figure 2 1 . 

Figure 25a is a schematic block diagram of the exemplary reservation 
15 management system (RMS) of Figure 21. 

Figure 25b illustrates the interaction between the RMS, the airline 
reservation system and the various databases depicted in Figure 25a, during a 
conventional pricing and allocation process and the CPO rules generation process of 
Figure 39. 

20 Figure 25c illustrates the actual demand over time for airline tickets 

within a given fare class, relative to forecasted demand. 

Figure 26 illustrates a sample table from the customer database of Figure 

22. 

Figure 27 illustrates a sample table from the airline database of Figure 

25 22. 

Figure 28 illustrates a sample table from the flight schedule database of 
Figures 22 and 24. 

Figures 29a and 29b, collectively, illustrate a sample table from the CPO 
database of Figure 22. 

30 Figure 30a illustrates a sample table from the secured airlines rules 

database of Figure 23. 
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Figures 30b and 30c. collectively, illustrate alternative sample tables to 
the secured airlines rules database of Figure 23. 

Figure 31 illustrates a sample table from the counteroffer rules database 

of Figure 23. 

Figure 32 illustrates a sample table from the secured airline audit 
database of Fi gure 23 . 

Figure 33 illustrates a sample table from the pricing and restrictions 
database of Figures 24 and 25a. 

Figure 34 illustrates a sample table from the seat allocation database of 
Figures 24 and 25a. 

Figure 35 illustrates a sample table from the forecast and demand 
analysis database of Figure 25a. 

Figures 36a through 36c, collectively, are a How chart describing an 
exemplary CPO management process implemented by the CPO management central 
15 server of Figure 22. 

Figures 37a and 37b, collectively, are a flowchart describing an 
exemplary evaluation process implemented by the secured airline server of Figure 23. 

Figure 38 is a flow chart describing an exemplary audit process 
implemented by the secured airline server of Figure 23. 

Figure 39 is a flow chart describing an exemplary CPO rule generation 
process implemented by the revenue management system of Figure 25a. 

Figures 40a and 40b, collectively, illustrate an alternative sample table 
from the CPO database of Figure 22 for a cruise implementation. 

Figure 41 illustrates an alternative sample table from the secured rules 
25 database of Figure 23 for a cruise implementation. 

Figure 42 is a flow chart describing an exemplary post-sell multi-bind 
process which may be implemented by the CPO management central server of Figure 
22. 

Figure 43 illustrates a sample table from the excluded operator 
30 counteroffer database which may be implemented by the CPO management central 
server of Figure 22 in conjunction with the flow chart of Figures 44a and 44b. 
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Figures 44a and 44b, collectively, are a flow chart describing an 
exemplary excluded seller CPO evaluation process which may be implemented by the 
CPO management central server of Figure 22. 

Figure 45 is a schematic block diagram illustrating a package 
5 conditional purchase offer (CPO) management system in accordance with one 
embodimenl of the present invention. 

Figure 46 is a schematic block diagram of the exemplary central 
controller of Figure 45. 

Figure 47 is a schematic block diagram of the exemplary secured server 

10 of Figure 45. 

Figure 48 is a schematic block diagram of an exemplary buyer or seller 
interface of Figure 45. 

Figure 49 illustrates a sample table from the buyer database of Figure 46. 

Figure 50 illustrates a sample table from the seller database of Figure 46. 
15 Figure 51 illustrates a sample table from the package CPO database of 

Figure 46. 

Figure 52 illustrates a sample table from the component CPO database of 

Figure 46. 

Figure 53 illustrates a sample table from the market price database of 

20 Figure 46. 

Figures 54a and 54b illustrate sample tables from the secured seller rules 
database of Figure 47. 

Figures 55a through 55c, collectively, are a flow chart describing an 
exemplary package CPO posting process implemented by the central controller of 
25 Figure 46. 

Figures 56a through 56c, collectively, are a flowchart describing an 
exemplary package CPO monitoring process implemented by the central controller of 
Figure 46. 

Figure 57 is a flow chart describing an exemplary component CPO rule 
30 evaluation process implemented by the secured server of Figure 47. 
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Figure 58A is a schematic block diagram illustrating a conditional 
purchase offer (CPO) management system in accordance with one embodiment of the 
present invention. 

Figure 58B is a schematic block diagram illustrating a conditional 
5 purchase offer (CPO) management system in accordance with an alternate embodiment 
of the present invention. 

Figure 59 is a perspective view of an illustrative telephone set utilized by 
the calling party of Figures 58A or 58B. 

Figure 60 is a schematic block diagram of a central server used by the 
10 CPO management system of Figure 58. 

Figure 6 1 illustrates a sample table from the customer database of Figure 

60. 

Figure 62 illustrates a sample table from the carrier database of Figure 

60. 

15 Figure 63 illustrates a sample table from the published rate database of 

Figure 60. 

Figure 64 illustrates a sample table from the CPO database of Figure 60. 

Figures 65a and 65b, collectively, are a flow chart describing an 
exemplary CPO management process implemented by the central server of Figure 60. 
20 Figures 66a and 66b, collectively, are a flow chart describing an 

exemplary IVRU process implemented by the central server of Figure 60. 

Figure 67 is a schematic view of a system according to one embodiment 
of the present invention. 

Figure 68 is a schematic view of a central controller used in the system 

25 of Figure 67. 

Figure 69 is a schematic view of a remote user terminal used in the 
system of Figure 67. 

Figure 70 is a schematic view of a venue controller used in the system of 

Figure 67. 

30 Fi S ure 7 1 a is a table illustrating the contents of an event table used in the 

system of Figure 67. 
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Figure 71b is a table illustrating the contents of a venue table used in the 
system of Figure 67. 

Figure 71c is a table illustrating the contents of a customer table used in 
the system of Figure 67. 

Figure 71d is a table illustrating the contents of an offer table used in the 
system of Figure 67. 

Figure 71 e is a table illustrating the contents of a transaction table used 
in the system of Figure 67. 

Figure 72a is a table illustrating the contents of a ticket table used in the 
system of figure 67. 

Figure 72b is a table illustrating the contents of a replacement ticket table 
used in the system of figure 67. 

Figures 73a-73g are flow diagrams depicting a method of submitting and 
accepting a guaranteed offer to buy an event ticket over the Internet according to. one 
embodiment of the present invention. 

Figure 74 is a schematic illustration of a system for processing the sale of 
products provided in accordance with the present invention. 

Figure 75a is a schematic illustration of an embodiment of a central 
controller of the system of Figure 74. 

Figure 75b is a schematic illustration of another embodiment of a central 
controller of the system of Figure 74. 

Figure 76 is a schematic illustration of a borrower database of the central 
controller of Figures 75a and 75b. 

Figure 77 is a schematic illustration of a lender database of the central 
controller of Figures 75a and 75b. 

Figure 78 is a schematic illustration of an offer database of the central 
controller of Figures 75a and 75b. 

Figure 79 is a schematic illustration of a credit report database of the 
central controller of Figures 75a and 75b. 

Figure 80 is a schematic illustration of a collateral database of the central 
controller of Figures 75a and 75b. 
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Figure 81a is a schematic illustration of a response database of the 
central controller of Figure 75a. 

Figure 81b is a schematic illustration of a rule database of the central 
controller of Figure 75b. 

Figures 82a and 82b are flowcharts showing a method for processing 
sales of a loan between a borrower terminal and lender terminals. 

Figure 82c is a flowchart showing another method for processing sales of 
a loan between a borrower terminal and lender terminals. 



Detailed Description of Preferred Embodiments 

The method and apparatus of one embodiment of the present invention 
will now be discussed with reference to Figures 1, 2, 3, and 4. In a preferred 
embodiment, the present invention includes central controller 200, seller interface 300, 
buyer interface 400, and associated databases. The present invention receives 
conditional purchase offers from buyers, makes them available for viewing by potential 
sellers, and allows sellers to bind them. Thus, a buyer is able to communicate his 
commitment to follow through on an offer to a seller, giving the seller confidence that if 
he can produce the goods, the buyer has the ready capacity to pay. 

SYSTEM ARCHITECTURE 

The system architecture of a first embodiment of the apparatus and 
method of the present invention is illustrated with reference to Figures 1 through 4. As 
shown in Figure 1, the apparatus of the present invention comprises seller interface 300, 
central controller 200 t and buyer interface 400 (collectively the "nodes"). Each node is 
connected via an Internet connection using a public switched phone network, such as 
those provided by a local or regional telephone operating company. Connection may 
also be provided by dedicated data lines, cellular, Personal Communication Systems 
("PCS"), microwave, or satellite networks. Seller interface 300 and buyer interface 400 
are the input and output gateways for communications with central controller 200. 

Using the above components, the present invention provides a method 
and apparatus to post conditional purchase offers, make them available to potential 
sellers, and allow sellers to bind the offers to form a legally binding contract 
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As shown in Figure 2, central controller 200 includes central processor 
(CPU) 205, cryptographic processor 210, RAM 215, ROM 220, payment processor 230, 
clock 235, operating system 240, network interface 245, and data storage device 250. 

A conventional personal computer or computer workstation with 
5 sufficient memory and processing capability may be used as central controller 200. In 
one embodiment it operates as a web server, both receiving and transmitting CPOs 100 
generated by buyers. Central controller 200 must be capable of high volume transaction 
processing, performing a significant number of mathematical calculations in processing 
communications and database searches. A Pentium microprocessor such as the 100 
10 MHz P54C, commonly manufactured by Intel Inc., may be used for CPU 205. This 
processor employs a 32-bit architecture. Equivalent processors include the Motorola 
120 MHz PowerPC 604 or Sun Microsystem's 1 66 MHz UltraSPARC-I. 

An MC68HC16 microcontroller, commonly manufactured by Motorola 
Inc., may be used for cryptographic processor 210. Equivalent processors may also be 
'15 used. This microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 
16 MHz configuration and requires less than one second to perform a 512-bit RSA 
private key operation. Cryptographic processor 210 supports the authentication of 
communications from both buyers and sellers, as well as allowing for anonymous 
transactions. Cryptographic processor 210 may also be configured as part of CPU 205. 
20 Other commercially available specialized cryptographic processors include VLSI 
Technology's 33MHz 6868 or Semaphore Communications 1 40 MHz Roadrunner284. 

Referring again to Figure 2, payment processor 230 comprises 
conventional microprocessors (such as the Intel Pentium), supporting the transfer and 
exchange of payments, charges, or debits, attendant to the method of the apparatus. 
25 Payment processor 230 may also be configured as part of CPU 205. Processing of 
credit card transactions by payment processor 230 may be supported with commercially 
available software, such as the Secure Webserver manufactured by Open Market, Inc. 
This server software transmits credit card numbers electronically over the Internet to 
servers located at the Open Market headquarters where card verification and processing 
30 is handled. Their Integrated Commerce Service provides back-office services necessary 
to run Web-based businesses. Services include on-line account statements, order-taking 
and credit card payment authorization, credit card settlement, automated sales tax 
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calculations, digital receipt generation, account-based purchase tracking, and payment 
aggregation for low-priced services. 

Data storage device 250 may include hard disk magnetic or optical 
storage units, as well as CD-ROM drives or flash memory. Data storage device 250 
5 contains databases used in the processing of transactions in the present invention, 
including buyer database 255, seller database 260, CPO database 265, counteroffer 
database 267, seller response database 270, purchase confirmation database 275, 
contract detail database 280, payment database 285, cryptographic key database 290, 
and audit database 295. In a preferred embodiment database software such as Oracle?, 

10 manufactured by Oracle Corporation, is used to create and manage these databases! 
Data storage device 250 also stores information pertaining to buyer account 297, seller 
account 298, and escrow account 299. 

Buyer database 255 maintains data on buyers with fields such as name, 
address, credit card number, phone number, ID number, social security number, 

15 electronic mail address, credit history, past system usage, public/private key 
information, etc. This information is obtained when the buyer first registers with the 
system, or immediately prior to posting his first CPO 100. Buyer database 255 also 
contains the tracking number of each CPO 100 generated by the buyer, and the tracking 
number of each seller response 1 10 and counteroffer 140 directed to the buyer's CPOs 
20 100. 

Seller database 260 maintains data on sellers with fields such as name, 
contact information, public/private key information, payment preferences, type of 
business, and goods sold. Contact information comprises a phone number, web page 
URL, bulletin board address, pager number, telephone number, electronic mail address, 
25 voice mail address, facsimile number, or any other way to contact the seller. Upon 
registration, the seller may be required to demonstrate evidence of ability to deliver on 
bound CPOs 100. An airline, for example, might submit a listing of the city pairs they 
service so that central controller 200 can quickly determine whether the airline is 
capable of satisfying a given CPO 100. 

30 CP0 database 265 tracks all CPOs 100 with fields such as status, 

tracking number, date, time, subject, price, expiration date, conditions, and buyer 
identification number. This database is valuable in the event of disputes between buyers 
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and sellers regarding payment, because details of the contract can be produced. CPO 
database 265 may also store bond certificate 172. 

Counteroffer database 267 tracks all counteroffers 140. The structure of 
this database is identical to CPO database 265, except for the addition of a field for CPO 
5 tracking number that allows counteroffer 140 to be correlated with a particular CPO 
100. 

Seller response database 270 tracks all seller responses 1 10 with fields 

such as seller name, seller ID number, date, time, seller response tracking number, and 

associated CPO tracking number. 
10 Purchase confirmation database 275 tracks the messages sent to the 

buyer and seller confirming completed transactions (bound contracts). Fields include 

buyer name, buyer ID number, seller name, seller ID number, purchase confirmation 

tracking number, and associated CPO tracking number. 

Contract detail database 280 contains form background provisions for 
15 inclusion in CPOs 100. These form provisions effectively fill the gaps between 

conditions specified by the buyer, specifying the generic contract details common to 

most CPOs 100. 

Payment database 285 tracks all payments made by the buyers with 
fields such as buyer name, buyer ED number, amount of payment, and associated CPO 
20 tracking number. This database may also store credit card numbers of buyers. 

Cryptographic key database 290 facilitates cryptographic functions, 
storing both symmetric and asymmetric keys. These keys are used by cryptographic 
processor 210 for encrypting and decrypting CPOs 100, seller responses 1 10, purchase 
confirmations 120, counteroffers 140, and buyer responses 150. 
25 Audit database 295 stores transactional information relating to the 

posting of CPOs 100, allowing it to be retrieved for later analysis. 

Buyer account 297 tracks all information pertaining to the buyer's 
account with fields such as buyer's name, bank and credit account numbers, and debit or 
credit transactions. This account may be a pointer to account data stored at the buyer's 
30 bank. 
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Seller account 298 tracks all information pertaining to the seller's 
account with fields such as seller's name, bank and credit account numbers, and debit or 
credit transactions. Buyer payments for CPOs 100 may be sent to this account. 

Escrow account 299 is an account that temporarily holds buyer funds 
before they are placed in seller account 298. 

Network interface 245 is the gateway to communicate with buyers and 
sellers through respective buyer interface 400 and seller interface 300. Conventional 
internal or external modems may serve as network interface 245. Network interface 245 
supports modems at a range of baud rates from 1200 upward, but may combine such 
inputs into a Tl or T3 line if more bandwidth is required. In a preferred embodiment, 
network interface 245 is connected with the Internet and/or any of the commercial on- 
line services such as America Online, CompuServe, or Prodigy, allowing buyers and 
sellers access from a wide range of on-line connections. Several commercial electronic 
mail servers include the above functionality. NCD Software manufactures 
"PosLOffice," a secure server-based electronic mail software package designed to link 
people and information over enterprise networks and the Internet. The product is 
platform independent and utilizes open standards based on Internet protocols. Users can 
exchange messages with enclosures such as files, graphics, video and audio. The 
system also supports multiple languages. Alternatively, network interface 245 may be 
20 configured as a voice mail interface, web site, BBS, or electronic mail address. 

While the above embodiment describes a single computer acting as 
central controller 200, those skilled in the art will realize that the functionality can be 
distributed over a plurality of computers. In one embodiment, central controller 200 is 
configured in a distributed architecture, wherein the databases and processors are 
housed in separate units or locations. Some controllers perform the primary processing 
functions and contain at a minimum RAM, ROM, and a general processor. Each of 
these controllers is attached to a WAN hub that serves as the primary communication 
link with the other controllers and interface devices. The WAN hub may have minimal 
processing capability itself, serving primarily as a communications router. Those 
skilled in the art will appreciate that an almost unlimited number of controllers may be 
supported. This arrangement yields a more dynamic and flexible system, less prone to 
catastrophic hardware failures affecting the entire system. The trusted server 
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embodiment provides more details of such a distributed environment, describing 
operations server 160, trusted server 165, and bonding agency 170. The hardware of 
these servers would be configured similarly to that described for central controller 200. 

Figures 3 and 4 describe seller interface 300 and buyer interface 400, 
5 respectively. In an exemplary embodiment they are both conventional personal 
computers having an input device, such as a keyboard, mouse, or conventional voice 
recognition software package; a display device, such as a video monitor; a processing 
device such as a CPU; and a network interface such as a modem. These devices 
interface with central controller 200. Alternatively, seller interface 300 and buyer 
10 interface 400 may also be voice mail systems, or other electronic or voice 
communications systems. As will be described further in the following embodiments, 
devices such as fax machines or pagers are also suitable interface devices. 

Referring now to Figure 3, there is described seller interface 300 which 
includes central processor (CPU) 305, RAM 315, ROM 320, clock 335, video driver 
15 325, video monitor 330, communication port 340, input device 345, modem 350, and 
data storage device 360. Cryptographic processor 335 and biometric device 355 may be 
added for stronger authentication as described later. A Pentium microprocessor such as 
the 1 00 MHz P54C described above may be used for CPU 305. Clock 335 is a standard 
chip-based clock which can serve to timestamp seller response 1 10 or counteroffer 140 
20 produced with seller interface 300. 

Modem 350 may not require high-speed data transfer if most seller 
responses 110 and counteroffers 140 produced are text-based and not too long. If a 
cryptographic processor is required, the MC68HC16 microcontroller described above is 
used. The structure of biometric device 355 will be described below in conjunction 
25 with the cryptographic authentication embodiment. 

Data storage device 360 is a conventional magnetic-based hard disk 
storage unit such as those manufactured by Conner Peripherals. Message database 370 
may be used for archiving seller responses 110 and counteroffers 140, while audit 
database 380 may be used for recording payment records and communications with 
30 central controller 200. 

Referring now to Figure 4, there is described buyer interface 400 which 
includes central processor (CPU) 405, RAM 415, ROM 420, clock 435, video driver 
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425, video monitor 430. cryptographic processor 435, communication port 440, input 
device 445, modem 450, and data storage device 460. All of these components may be 
identical to those described in Figure 3. 

There are many commercial software applications that can enable the 
communications required by seller interface 300 or buyer interface 400, the primary 
functionality being message creation and transmission. Eudora Pro manufactured by 
QuaJcomm Incorporated, for example, provides editing tools for the creation of 
messages as well as the communications tools to route the message to the appropriate 
electronic address. When central controller 200 is configured as a web server, 
conventional communications software such as the Netscape navigator web browser 
from Netscape Corporation may also be used. The buyer and seller may use the 
Netscape Navigator browser to transmit CPO 100, seller response 1 10 or counteroffers 
140. No proprietary software is required. 

ONLINE EMBODIMENT 
15 In on e embodiment of the present invention, communications between 

buyers and sellers take place via electronic networks, with central controller 200 acting 
as a web server. The buyer logs on to central controller 200, creates CPO 100, and then 
disconnects from the network. CPO 100 is made available to potential buyers by 
posting CPO 100 on the web page of central controller 200. Periodic maintenance is 
20 performed by central controller 200 to ensure that active CPOs 100 have not expired, 
and that the buyer has sufficient credit available to pay a seller who elects to bind CPO 
100. Seller responses 1 10 are transmitted electronically to central controller 200 which 
contacts the buyer to indicate that CPO 100 has been bound. Central controller 200 
transfers credit card information to the seller as soon as CPO 100 is bound. 
25 witn reference to Figure 5. there is described the process by which the 

buyer formulates CPO 100. At step 500, the buyer logs on to central controller 200 
using buyer modem 450 of buyer interface 400, establishing a communication link. It 
should be noted that the buyer may be an individual, a corporation, a partnership, a 
government, or any other entity. In one embodiment, central controller 200 has a page 
30 on the World Wide Web, allowing the buyer to provide information through the 
interface of conventional web browser software such as Netscape Navigator, 
manufactured by Netscape, Inc. At step 510, the buyer selects the subject of the goods 
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he wants to purchase by selecting from a list of possible subjects. As shown in box 515, 
subjects might include airline tickets, hotel rooms, rental cars, insurance, mortgages, 
clothing, etc. After the subject is selected, a form is displayed on video monitor 430 of 
buyer interface 400. This form is an electronic contract with a number of blanks to be 
5 filled out by the buyer, with each blank representing a condition of CPO ] 00. 

At step 520, the buyer enters a description of the goods. A business 
traveler, for example, might want to fly from San Francisco to New York. The 
description of the goods might be two first class round-trip tickets between those city 
pairs, leaving May 7 and returning May 12. There would be a place on the form for 

10 originating city, destination city, date of departure, date of return, number of tickets, 
class of service, etc. The buyer simply fills in the blanks. The buyer then adds other 
conditions at step 530. The buyer, for example, may only want a nonstop ticket on a 
flight arriving at the destination city before midnight. These conditions would be 
similarly entered into CPO 100. As indicated in box 535, conditions could include the 

15 provision that a flight must arrive before midnight, a hotel room must be non-smoking, 
or a rental car must not be a compact. Conditions are the terms of CPO 100, allowing 
the buyer to tailor CPO 100 for his specific needs. Conditions may also be based on 
other conditions. For example, one condition might state that four out of five other 
specified conditions must be met. Alternatively, each condition of CPO 100 could be 

20 given a point value, with CPO 100 requiring only that conditions be satisfied up to a 
certain total point value. For example, the buyer may indicate that a window seat is 
worth two points, an aisle seat one point, and a nonstop flight four points, etc. CPO 100 
could require that ten "points" must be met in order to satisfy the conditions of CPO 
100. Conditions could also indicate that for twenty-four hours following the first 

25 attempted binding of CPO 100, other sellers may make offers to bind, with the original 
binding seller completing the contract only if no better offer has been received. 
Conditions could even be based on external events. For example, the buyer could create 
CPO 100 which offered to buy airline tickets only in the event that it was snowing in 
November in the destination city. 

30 At step 540, the buyer adds an expiration date to CPO 100, if desired. 

This allows a buyer to post CPO 100 without worrying that he will later be bound after 
his needs have changed. At step 550, the buyer enters a price. In a CPO 100 for a 
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rental car, for example, the buyer may enter a price of fifty dollars for a three-day rental. 
At step 560. the buyer attaches his name or a unique user ID number to CPO 100. This 
ID number is received from central controller 200 when the buyer registers for the 
service, or is chosen by the buyer and then registered with central controller 200 by 
phone. Central controller 200 maintains a database of buyer ID numbers in buyer 
database 255, and issues (or allows) only unique numbers. If less security is required, 
the user's telephone number could serve as the ID number since it has the advantages of 
being both unique and easily remembered. If additional security is required, those 
procedures described in the cryptographic embodiment may be implemented. 

Once the above elements have been developed, the buyer transmits them 
to central controller 200 at step 570. The buyer docs this by clicking on a "send" button 
located on the screen in which he entered the terms of CPO 100. At step 580, 
boilerplate legal language is added to the components of CPO 100 to form a complete 
CPO 100. The legal language is pulled from contract detail database 280 that stores a 
plurality of paragraphs. These paragraphs are linked together with the above contract 
elements to form a complete CPO 100. The only element missing which prevents CPO 
100 from being recognized as a legitimate contract is the name and signature of the 
seller. 

Instead of a World Wide Web-based interface, buyers may also transmit 
CPO 100 data via electronic mail, voice mail, facsimile, or postal mail transmissions. 
With voice mail, the buyer calls central controller 200 and leaves CPO 100 in audio 
form. These CPOs 100 may be transcribed into digital text at central controller 200, or 
made available to potential sellers in the same audio format. In a postal mail 
embodiment, central controller 200 acts more like a router, directing CPOs 100 to the 
potential sellers, creating multiple copies of CPO 100 if necessary. CPO 100 may also 
be posted to bulletin boards or web pages operated by central controller 200. Central 
controller 200 supports a plurality of transmission methods, allowing for a wide variety 
of formats of CPOs 100. Some formats may be changed, however, before further 
processing by central controller 200. CPOs 100 transmitted by mail in paper form, for 
example, may be scanned-in and digitized, using optical character recognition software 
to create digital text. These embodiments are more fully described in the off-line 
embodiment described later. 
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Referring now to Figure 6, CPO 100 is received and checked to see that 
sufficient credit is available to cover the stated price of CPO 100, before CPO 100 is 
made available to potential sellers. At step 600, central controller 200 extracts price and 
expiration date information from CPO 100. At step 610, payment processor 230 
5 submits a pre-authorization of the price of CPO 100 to the credit card clearinghouse. 
This serves to "lock up" a portion of the available credit on the buyer's credit card, 
preventing him from using up this credit while CPO 100 is still active. At step 620, the 
credit card clearinghouse responds to the pre-authorization, indicating whether 
sufficient credit is available. If sufficient funds are not available to cover the price of 

10 CPO 100, another credit card number is requested from the buyer at step 630. Once an 
additional credit card number has been transmitted, central controller 200 then 
resubmits the pre-authorization at step 610. At step 640, the expiration date of CPO 100 
is checked to see if it has already expired. If it has expired, CPO 100 is rejected at step 
650 and returned to the buyer. If CPO 100 has not yet expired, it is accepted at step 

15 660. 

Referring now to Figure 7, there is illustrated an embodiment in which 
CPO 100 is activated and made available to potential sellers. At step 700, a unique 
tracking number is added to CPO 100. Central controller timestamps CPO 100 at step 
710, and then stores CPO 100 in CPO database 265. CPO database 265 contains a 

20 record for each CPO 100, and includes fields such as status, subject, tracking number, 
timestamp, description of goods, price, expiration date, conditions, and buyer ID 
number. The status field has values of "pending," "active," "expired," and "completed." 
A status of "pending" means that the CPO is not currently available to potential sellers. 
Either it is still being processed by central controller 200, or it has been temporarily 

25 suspended by the buyer. An "active" CPO 100 is available to potential sellers and can 
be bound. An "expired" CPO 100 can no longer be bound. CPOs 100 that have been 
bound by a seller have a status of "completed." 

After being stored at step 720, CPO 100 may go through a series of 
processing steps. One step, if necessary, is language translation, either creating a 

30 standard language that all CPO 100s must be written in, or translating to the language 
most appropriate for the sellers to which it will be sent. This translation is provided by 
language experts at central controller 200, or by automatic translation software such as 
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Systran Professional, manufactured by Systran Software. Twelve bi-directional 
language combinations are available, including English to/from French, Italian, 
German, Spanish, Portuguese, and Japanese. Another step, if necessary, is to edit for 
spelling or grammatical errors. CPO 100 might also be reviewed for clarity. Any CPO 
5 100 with an unclear term or condition would be returned to the buyer for clarification. 
A buyer listing a destination city of "Chicago" might have CPO 100 returned for 
clarification or correction. 

Referring again to Figure 7, the status of the database record for CPO 
100 is set to "active" at step 730. At step 740, the subject of CPO 100 is extracted from 
10 the subject field. At step 750. CPO 100 is posted in an appropriate subject area. This 
allows central controller 200 to display CPO 100 only to the most appropriate sellers. 
In a World Wide Web environment, central controller 200 has a web page for each 
possible subject area. Thus all CPOs 100 requesting airline tickets would be displayed 
on the airline ticket web page. This makes it much easier for potential sellers to find 
15 appropriate CPOs 100 they might want to bind as they can go right to the subject whose 
goods they can provide. In an alternative embodiment. CPO 100 is electronically 
mailed to potential sellers, either individually or in groups. Potential sellers could elect 
to receive all CPOs 100, only those CPOs 100 in their subject area, or a subset of CPOs 
100 representing a particular condition. For example, a car rental company might 
20 request that all car rental CPOs 1 00 for luxury cars be sent to them. 

In an embodiment in which CPOs 100 are being transmitted to the seller, 
it is important to note that there are a number of hardware options for seller interface 
300. Suitable seller interfaces 300 include fax machines, personal digital assistants 
(PDAs) with wireless connections, and beepers or pagers. For example, a rare coin 
25 dealer could instruct central controller 200 to beep him whenever CPO 100 appeared for 
Morgan Silver Dollars, providing details of CPO 100 over the beeper network, or 
informing the seller to log on to central controller 200 for further details. 

Referring now to Figure 8, there is illustrated a procedure for the 
maintenance of CPOs 100. At step 800, central controller 200 searches CPO database 
265. At step 810, the expiration date field of each database record of CPO 100 is 
compared to the current date. If the expiration date of CPO 100 is earlier than the 
current date, the status of CPO 100 is changed to "expired" at step 820. At step 830. 

26 
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payment processor 230 contacts credit card clearinghouse to verify that the buyer's 
credit card is still valid. If the card is not valid, the status of CPO 100 is changed to 
"expired" at step 840. The maintenance process is completed at step 850 once all 
"active" CPO database records have been examined. 
5 Figure 9 illustrates the process by which a potential seller selects CPO 

100. At step 900, the potential seller logs on to central controller 200 using modem 350 
of seller interface 300. At step 910, the potential seller selects an appropriate subject 
area. For example, a large Chicago hotel that had just experienced the cancellation of a 
block of rooms for a convention might search in the hotel subject area in the hopes of 

10 finding a CPO 100 requesting a room in Chicago on those dates. Al step 920, the 
potential seller browses the list of available CPOs 100 (i.e. those with a status of 
"active"). CPOs 100 may be listed with minimal details, with additional information 
available only if the potential seller is interested in binding CPO 100. A hotel CPO 100 
might be listed as "hote)-09/16/96-Chicago-single occupancy-$85." A potential seller 

15 wanting more information about CPO 100 may request additional data at step 940. In 
one embodiment, each CPO 100 is hyperlinked to a separate web page that provides 
complete details. The potential seller clicks on CPO 100 and is immediately transferred 
to the page of supporting detail. This detail might include the required type of bed, 
fitness facilities, and restaurants. In another embodiment, CPO 100 is electronically 

20 transmitted directly to the seller, via electronic mail, fax, telephone, beeper, etc. 

Figures 10 and 1 1 illustrate the process by which CPO 100 is bound by a 
seller. At step 1000, the potential seller selects CPO 100 that he would like to bind, 
developing seller response 110 that represents his intention to bind. At step 1010, 
central controller 200 receives seller response 110 from the potential seller. Central 

25 controller 200 then timestamps seller response 1 10 and authenticates the identity of the 
seller, as well as verifying his probable capacity to deliver the goods. The timestamp 
allows central controller 200 to determine the first unconditional acceptance to be 
received. If two seller responses 1 10 are received within a few seconds of each other, 
the timestamp allows central controller 200 to decide which was received first. 

30 Alternatively, the timestamp may be appended to seller response 1 10 at the time it is 
transmitted from seller interface 300, using clock 335 of seller interface 300. 
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Authentication of the seller's identity involves central controller 200 
extracting the seller ID from seller response 110 and looking up the seller's identity in 
seller database 260. Information in seller database 260 then provides an indication of the 
seller's ability to deliver the goods. Before a seller can bind CPO 100 for an airline 
ticket, for example, central controller 200 must authenticate that the seller is an airline. 
If necessary, central controller 200 may verify that the seller can provide the specific 
good requested. Rather than just verifying that the seller is an airline, central controller 
200 may verify that it serves the city pairs requested by the buyer. In another 
embodiment, the seller incorporates seller response 1 10 into CPO 100, signing CPO 100 
by adding an indication that the contract is agreed to. This indication could be a digital 
signature, or could involve adding a symbol or indicia representative of the seller. 

Central controller 200 then verifies the status of CPO 100 at step 1030, 
determining whether or not the status of CPO 100 is "active" at step 1040. If CPO 100 is 
currently "active," a unique tracking number is added to seller response 110 at step 
1060. Central controller 200 then stores seller response 1 10 in seller response database 
270 at step 1070. If the status of CPO 100 is not "active" at step 1040, seller response 
1 10 is refused by central controller 200 and transmitted back to the potential seller at 
step 1050. 

In another embodiment, the seller transmits seller response 110 directly 
to the buyer at step 1010. The buyer may then send seller response 1 10 to central 
controller 200 for verification and authentication, or he may choose to accept seller 
response 1 10 without verification and authentication. 

In Figure 1 1, the payment process is begun at step 1 100 when the credit 
card number and approval code for the selected CPO 100 is transmitted to the seller. At 
25 step 1 1 10 CPO 100 is bound, turning CPO 100 into a legally binding contract between 
the buyer and seller. The binding process requires that the status of CPO 100 be 
changed to "completed," preventing subsequent sellers from being able to bind CPO 
100. The binding process also requires that the seller ED be added to CPO 100. At step 
1120, central controller 200 sends purchase confirmation 120 to the seller and then 
30 sends it to the buyer at step 1 1 30. 

In another embodiment, multiple sellers may bind CPO 100. In this case, 
CPO 100 may maintain its status of "active" until a given number of sellers have 
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responded, and only then is the status of CPO 100 changed to "completed." For 
example, a rare coin dealer may post CPO 100 offering a hundred dollars for a specific 
type of coin. A condition of CPO 100 may state that the offer is open to the first ten 
sellers to respond, allowing for ten bindable contracts. Another option is to open CPO 
5 100 to any number of bindings, or any number of bindings up to the funds available by 
the buyer. 

There are many methods by which the providers of the system could 
derive a revenue stream. In one embodiment, a flat fee is charged for every CPO 100 
submitted. There could also be flat fees that would cover any number of CPOs 100 over 

10 a given period of time, allowing buyers to subscribe to (he service much as they would 
subscribe to a newspaper. In another embodiment, central controller 200 calculates a 
discounted value of the price in which sellers receive only a percentage of the price of 
CPO 100. In another embodiment, advertisers pay to have messages listed along with 
CPOs 100, supplementing the costs of operating the system. Alternatively, the method 

15 and apparatus of the present invention may be employed without a payment feature. 

Figure 12 illustrates the exchange of goods between buyer and seller. At 
step 1200, the seller transfers the specified goods to the buyer. This transfer could 
involve the delivery of physical goods as well as digital goods. Physical goods might 
include cars, jewelry, computer equipment, etc. Digital goods might include 

20 documents, tickets, access codes, etc. A hotel, for example, might transfer a 
confirmation number to the buyer, to be presented upon check-in at the hotel. At step 
1210, the buyer examines the delivered goods to see if they meet all conditions and 
terms of CPO 100. A buyer purchasing a hotel room, for example, would verify that the 
room was for the correct date and was in the correct city. At step 1220, if the goods do 

25 not meet the buyer's conditions as described-in CPO 100 the buyer contacts an arbiter at 
central controller 200 for dispute resolution. This process is described in more detail in 
the dispute resolution embodiment described later. At step 1240 the transaction is 
complete. 

PAYMENT PREFERENCES 
30 Figure 13 illustrates a protocol in which central controller 200 establishes 

buyer account 297. At step 1300, the buyer selects his preferred method of payment. 
Preferred methods might include credit cards, personal checks, electronic funds transfer, 
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digital money, etc. At step 1310, the buyer transmits payment data corresponding to his 
preferred method of payment to central controller 200. As indicated by box 1315, such 
payment data might include credit card number or bank account number. These 
payment methods are meant to be merely illustrative, however, as there are many 
5 equivalent payment methods commonly known in the art that may also be used. If the 
buyer wants to pay by credit card, for example, payment data would include his credit 
card account number, expiration date, name of issuing institution, and credit limit. For 
electronic funds transfer, payment data includes the name of the buyer's bank and his 
account number. At step 1320, central controller 200 stores payment data and payment 
10 preferences in payment database 285. 

At step 1330, central controller 200 establishes buyer account 297 that 
either stores money transferred by the buyer or serves as a pointer to an account of the 
buyer outside the system. For buyers using credit cards, for example, buyer account 
297 contains the credit card number, expiration date, and name of issuing institution. 
Buyers could also transfer money to central controller 200 to be stored in buyer account 
297, which would operate like a conventional checking account. Central controller 200 
would send a check to the seller written on buyer account 297. Alternatively, central 
controller 200 could electronically move the funds directly from buyer account 297 to 
seller account 298. At step 1340, central controller 200 contacts the bank or card issuer 
20 to confirm that funds are available. A buyer is thus unable to use a credit card with no 
credit available to establish buyer account 297. 

The above protocols may be similarly applied to sellers, allowing for the 
creation of seller account 298. The primary difference being that seller account 298 is 
primarily used for deposits, with money flowing from seller to buyer in the case of 
deposit returns or refunds when the buyer does not find the received goods acceptable. 
Verification of funds available is therefore not as important for sellers. 

Although the on-line embodiment describes a protocol in which central 
controller 200 transmits credit card information to the seller for processing, there are of 
course many payment protocols under which payment may be transferred from buyer to 
seller. In one embodiment, processing the credit card is performed by central controller 
200, not the seller. Central controller 200 looks up the credit card number of the buyer 
in payment database 285. This credit card number is transmitted to payment processor 
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230. Payment processor 230 contacts the credit card clearinghouse to get an 
authorization number. The billable amount appears on the credit card statement of the 
buyer in his monthly statement. The clearinghouse posts this amount to seller account 
298. Central controller 200 updates payment database 285 to indicate that payment has 
5 been made. Central controller 200 could also arrange for payment to be made directly 
between buyer and seller by providing payment information to each party. The buyer, 
for example, might receive the checking account number of the seller. Account 
information could also be embedded into CPO 100 and seller response 110, allowing 
buyer and seller to complete payment once they each had a copy of CPO 100. 

10 Another method of payment involves procedures using digital cash. 

Central controller 200 looks up the buyer's electronic delivery address in payment 
database 285. This address is transmitted to payment processor 230, with the digital 
cash being downloaded from the buyer. Central controller 200 updates payment 
database 285 to indicate that payment has been made. This address might be an 

15 electronic mail address if the digital cash is to be transferred by electronic mail, or it 
could be an Internet Protocol address capable of accepting an on-line transfer of digital 
cash. This electronic delivery address is sent to payment processor 230. The digital 
cash is downloaded to seller account 298 or directly to the seller. Central controller 200 
then updates payment database 285 to indicate that payment has been made. Using 

20 these digital cash protocols, it is possible for the buyer to include payment along with 
CPO 100 in electronic form. 

The practice of using digital cash protocols to effect payment is well 
known in the art and need not be described here in detail. For reference, one of ordinary 
skill in the art may refer to Daniel C. Lynch and Leslie Lundquist, Digital Money, John 

25 Wiley & Sons, 1996; or Seth Godin, Presenting Digital Cash, Sams Net Publishing, 
1995. 

DELAYED PAYMENT EMBODIMENT 
Although the on-line embodiment describes a protocol in which sellers 
receive payment immediately upon binding CPO 100, other embodiments may be 
30 implemented in which payment is delayed until the goods have been received by the 
buyer, or delayed until some predetermined date. Partial payments and installment 
payments are also supported by the system 
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Escrow account 299 allows payment to be delayed until the seller 
completes delivery of the goods, while at the same time ensuring that the buyer will in 
fact make payment. Central controller 200 establishes escrow account 299 as a 
temporary holding account. When the seller binds CPO 100 at step 1110, funds are 
5 transferred from buyer account 297 to escrow account 299. Only after the goods have 
been received by the buyer are funds transferred from escrow account 299 to seller 
account 298. The buyer may transmit a digitally signed release message to central 
controller 200, authorizing the release of the escrowed funds to the seller. 

In another embodiment, the buyer makes a partial payment when CPO 
10 100 is bound, and then completes payment when the goods are received. The fraction 
of the offered price of CPO 100 to be paid upon binding is a condition of CPO 100 and 
is stored in payment database 285 when CPO 100 is bound. Central controller releases 
this portion of the funds at step 1110, and then releases the remaining portion after 
goods have been delivered at step 1200. The partial payment made upon binding may 
15 be non-refundable. This would allow a hotel, for example, to sell hotel room 
reservations that are cancelable on two days notice, with cancellations within the two- 
day period resulting in forfeiture of deposit. 

In yet another embodiment. CPO 100 describes the use of installment 
payments. The first payment is made when CPO 100 is bound, followed by regular 
payments as specified in the conditions of CPO 100. The dates at which payments are 
to be made are stored in payment database 285. 

COUNTEROFFER EMBODIMENT 
In one embodiment of the present invention, sellers respond to CPO 100 
not by binding it, but by making a counteroffer with modified and/or additional 
25 conditions. An airline, for example, might view CPO 100 for a first class ticket for five 
hundred dollars. The airline may be willing to sell for six hundred dollars, and thus 
want to develop and issue a counteroffer rather than electing to bind CPO 100. This 
counteroffer is similar to CPO 100 except that the buyer is binding the seller instead of 
the seller binding the buyer. The counteroffer is also directed to a specific party (the 
30 buyer), unlike CPO 1 00 that may be directed to a plurality of sellers. 

Figure 18 illustrates the development of counteroffer 140. At step 1800, 
the potential seller selects CPO 100 for which he wants to make a counteroffer. At step 
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1810, the seller prepares counteroffer 140 with modified conditions. The seller follows 
the same process that the buyer uses to generate CPO 100 (steps 500 through 580), 
selecting the conditions of counteroffer 140. Alternatively, the seller is presented with 
an electronic copy of CPO 100 and is allowed to edit those conditions that the seller 
5 wants to change. For example, a car rental company might take the buyer's request for a 
ten dollar per day luxury car and counteroffer with a twenty-dollar per day compact car. 
At step 1820, the seller attaches the tracking number of CPO 100 to counteroffer 140. 
Central controller 200 receives counteroffer 140 at step 1830, setting the status to 
"active." Central controller 200 then adds a unique tracking number to counteroffer 140 
10 at step 1840, and stores it in counteroffer database 267 at step 1850. Central controller 
200 extracts the tracking number of CPO 100 attached to counteroffer 140 in order to 
find the buyer to whom counteroffer 140 is transmitted at step 1860. 

Figure 19 illustrates the process by which the buyer responds to 
counteroffer 140. At step 1900, the buyer decides whether or not to bind counteroffer 
15 140. If he does not bind, counteroffer 140 is transmitted back to the potential seller at 
step 1910. If the buyer does decide to bind, buyer response 150 is transmitted to central 
controller 200 at step 1920. At step 1930, funds are removed from buyer account 297 
and placed in seller account 298. At step 1940. the status of counteroffer 140 is 
changed to "completed." Purchase confirmation 120 is transmitted to the seller at step 
20 1950 and transmitted to the buyer at step 1960. Procedures for the exchange of goods 
are completed as described in Figure 12. 

OFF-LINE EMBODIMENT 
In one embodiment of the present invention, buyers and sellers 
communicate in an off-line manner with central controller 200. Rather than sending 
25 electronic mail or using web-based servers, buyers and sellers use a telephone, fax 
machine, postal mail, or other off-line communication tool. 

A buyer may use a telephone, for example, to generate CPO 100. The 
buyer calls central controller 200 and is connected with an agent. The buyer provides 
the terms of CPO 100 such as subject, description of goods, conditions, expiration date, 
30 price, etc. The buyer also provides his buyer ED, password, or private key so that 
central controller 200 can authenticate his identity. The agent puts this data into digital 
form by typing it into a terminal and then adds legal language to form CPO 100. CPO 
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100 is then transmitted to central controller 200 where it is made available to potential 
sellers as described in the on-line embodiment. 

In an alternative embodiment, the buyer calls central controller 200 and 
is connected with a conventional Interactive Voice Response Unit (IVRU) which allows 
5 the buyer to enter some or all of the terms of CPO 100 without the assistance of a live 
agent. The buyer initially selects from a menu of subjects using the touch-tone keys of 
his phone, and then the call is either directed to a live agent specializing in that subject 
area, or the buyer is prompted for further terms of CPO 100. 

Potential sellers may also use a telephone to browse and bind CPOs 100. 

10 The potential seller calls central controller 200 and selects a subject. Central controller 
200 then converts the text of each CPO 100 into audio form, reading the entire list to the 
potential seller. At any time during the reading of CPOs 100, the potential seller may 
press a combination of keys on his telephone to select CPO 100 for binding. The seller 
enters seller ID number and is authenticated by central controller 200 prior to the 

15 binding of CPO 100. Potential sellers could also enter parameters before having the list 
of CPOs 100 read to them. An airline, for example, might request that all airline CPOs 
100 for more than eight hundred dollars be read, skipping any CPO 100 with a lower 
price. 

Buyers may also communicate with an agent at central controller 200 
20 through faxes or postal mail. The agent receives the message and proceeds to digitize it 
and form CPO 100 as described above. 

CRYPTOGRAPHIC AUTHENTICATION EMBODIMENT 
In the previous embodiments, authentication of the buyer and seller 
involves checking the attached ID or name and comparing it with those stored in seller 
25 database 260 and buyer database 255. Although this procedure works well in a low 
security environment, it can be significantly improved through the use of cryptographic 
protocols. These protocols not only enhance the ability to authenticate the sender of a 
message, but also serve to verify the integrity of the message itself, proving that it has 
not been altered during transmission. A small airline, for example, couid be prevented 
30 from binding CPOs 100 requiring performance by a large carrier as their identity would 
not be authenticated. Encryption can also prevent eavesdroppers from learning the 
contents of the message. A competing airline, for example, could be prevented from 
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reading any intercepted seller response 110 generated by another competitor. Such 
techniques shall be referred to generally as cryptographic assurance methods, and will 
include the use of both symmetric and asymmetric keys as well as digital signatures and 
hash algorithms. 

5 The practice of using cryptographic protocols to ensure the authenticity 

of senders as well as the integrity of messages is well known in the art and need not be 
described here in detail. For reference, one of ordinary skill in the art may refer to 
Bruce Schneier, Applied Cryptography, Protocols, Algorithms, And Source Code In C, 
(2d Ed, John Wiley & Sons, Inc., 1996). 
10 Figure 14 describes a symmetric key embodiment in which the seller and 

central controller 200 share a key. Thus both encryption and decryption of seller 
response 1 10* are performed with the same key. This encryption may be implemented 
with an algorithm such as DES (U.S. Government standard, specified in FIPS PUB 46), 
or with any of several algorithms known in the art such as IDEA, Blowfish, RC4, RC2, 

15 SAFER, etc. The seller encrypts seller response 110 with his assigned symmetric key at 
step 1400, using cryptographic processor 310 of seller interface 300. The key may be 
stored in message database 370 or otherwise stored or memorized by the seller. The 
encrypted seller response 110 is then transmitted to cryptographic processor 210 of 
central controller 200 at step 1410. Cryptographic processor 210 extracts the seller ID 

20 from seller response 1 10 at step 1420 and looks up the symmetric key of the seller in 
cryptographic key database 290 at step 1430, decrypting seller response 1 10 with this 
key at step 1440. Cryptographic key database 290 contains algorithms and keys for 
encrypting, decrypting and/or authenticating messages. At step 1450, if the resulting 
message is intelligible, then it must have been encrypted by the same key, 

25 authenticating that the seller must have indeed been the author of seller response 1 1 0. 

This procedure makes it significantly more difficult for an unauthorized 
seller to represent himself as a legitimate seller. Without cryptographic procedures, an 
unauthorized seller who obtained a sample seller response 1 10 from a legitimate seller 
would be able to extract the seller ID and then attach this ID number to unauthorized 

30 seller responses 1 10. When seller response 1 10 has been encrypted with a symmetric 
key, however, an unauthorized seller obtaining a sample seller response 110 only 
discovers the seller's ID number, not the symmetric key. Without this key, the 
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unauthorized seller cannot create a seller response 1 10 that will not be discovered by 
central controller 200, since he cannot encrypt his message in the same way that the 
authorized seller could. The symmetric key protocol also ensures that seller response 
1 10 has not been tampered with during transmission, since alteration of the message 
requires knowledge of the symmetric key. An encrypted seller response 1 10 also 
provides the seller with more anonymity. 

Referring now to Figure 15, there is shown an asymmetric key protocol 
in which seller response 110 is encrypted with a private key and decrypted with a public 
key. Two such algorithms for this procedure are RSA and DSA. At step 1500, the 
seller encrypts seller response 1 10 with his private key using cryptographic processor 
310, transmitting seller response 110 to central controller 200 at step 1510. 
Cryptographic processor 210 extracts the seller ID at step 1520 and looks up the seller's 
associated public key in cryptographic key database 290 at step 1530, decrypting seller 
response 110 with this public key at step 1540. As before, if seller response 110 is 
15 intelligible then central controller 200 has authenticated the seller at step 1550. Again, 
unauthorized sellers obtaining seller response 110 before it was received by central 
controller 200 are not able to undetectably alter it since they do not know the private 
key of the seller. Unauthorized sellers would, however, be able to read the message if 
they managed to obtain the public key of the seller. Message secrecy is obtained if the 
20 seller encrypts seller response 1 10 with his public key, requiring the attacker to know 
the seller's private key to view seller response 1 10. 

Figure 16 shows a cryptographic technique using digital signatures to 
provide authentication and message integrity. One such algorithm is DSA (Digital 
Signature Algorithm), the U.S. Government standard specified in FIPS PUB 186. As in 
25 the asymmetric protocol described above, each seller has an associated public and 
private key. The seller signs seller response 1 10 with his private key at step 1600 with 
cryptographic processor 310 and transmits it to central controller 200 at step 1610. 
Central controller cryptographic processor 210 extracts the seller ID at step 1620 and 
looks up the seller's public key at step 1630, verifying the signature using seller 
30 response 1 10 and the public key of the seller at step 1640. If seller response 1 10 is 
intelligible, then central controller 200 accepts seller response 1 10 as authentic at step 
1650. 
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Referring now to Figure 17, there is described a cryptographic technique 
using message authentication codes for verifying the authenticity and integrity of seller 
response 110. In the hash protocol of the present invention, the seller and central 
controller 200 share a symmetric key, which the seller includes in a hash of seller 
5 response 110 at step 1700. In the hash protocol, a one-way function is applied to the 
digital representation of seller response 1 10, generating a code that acts much like the 
fingerprint of seller response 110. Any of the MAC algorithms, such as RIPE-MAC, 
BC-Hash, CBC-MAC, and the like may be applied in this application. After 
transmitting seller response 110 to central controller 200 at step 1710, cryptographic 

10 processor 210 extracts seller ID from seller response 1 10 at step 1720. Then 
cryptographic processor 210 looks up the seller's symmetric key at step 1730 and hashes 
seller response 1 10 with this symmetric key at step 1740, comparing the resulting hash 
value with the hash value attached to seller response 110. If the values match at step 
1750, the integrity of seller response 1 10 is verified along with the authenticity of the 

15 seller. 

Although cryptographic techniques can provide greater confidence in the 
authenticity of seller response 1 10, they are useless if the seller's cryptographic keys are 
compromised. An attacker obtaining the symmetric key of another seller is 
indistinguishable from that seller in the eyes of central controller 200. There is no way 

20 to know whether the seller was the true author of seller response 110, or an attacker 
with the right cryptographic keys. One way to solve this problem (known as undetected 
substitution) is to use biometric devices such as a fingerprint reader, voice recognition 
system, retinal scanner and the like. These devices incorporate a physical attribute of 
the seller into seller response 1 10, which is then compared with the value stored in seller 

25 database 260 at central controller 200. In the present invention, such devices attach to 
seller interface 300. 

Fingerprint verification, for example, may be executed before the 
creation of seller response 1 10, during the generation of seller response 1 10 in response 
to prompts from central controller 200, at some predetermined or random times, or 

30 continuously by incorporating the scanning lens into seller interface 300 such that the 
seller is required to maintain his finger on the scanning lens at all times for continuous 
verification while seller response 1 10 is generated. 
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An example of such an identification device is the FC100 
FINGERPRINT VERIFIER available from Startek. a Taiwanese company. The FC100 
is readily adaptable to any PC via an interface card. The fingerprint verifier utilizes an 
optical scanning lens. The seller places his finger on the lens, and the resulting image is 
scanned, digitized, and the data compressed and stored in memory. Typically, a 256- 
byte file is all that is required. Each live-scan fingerprint is compared against the 
previously enrolled/stored template, stored in data storage device 360. If the prints do 
not match, the cryptographic algorithms executed by cryptographic processor 335 may 
prevent the seller from generating a seller response 1 10. 

In a voice verification embodiment, the seller's voice is used to verify his 
identity. This embodiment has the advantage of not requiring the use of any specialized 
hardware since it can be implemented over a standard phone connection. The seller's 
identity is verified at central computer 200. The process of obtaining a voice-print and 
subsequently using it to verify a person's identity is well-known in the art, and therefore 
15 need not be described in detail herein. One of ordinary skill in the art may refer to 
SpeakEZ, Inc. for voice identification/verification technology. Conventional speaker 
identification software samples the seller's voice. This sample is stored at central 
controller 200 in seller database 260. Each time the seller wants to transmit seller 
response 1 10 to central controller 200, he is required to call central controller 200 and 
20 speak into the phone at the prompt for a voice sample. If this sample matches that 
stored in seller database 260, the seller is provided a password which is incorporated 
into the digital signature appended to seller response 1 10. Any seller response 110 
received without an appropriate voice match password is not accepted. The voiceprint 
may also be stored in a database within data storage device 360 of seller interface 300, 
25 to verify the seller's identity locally prior to allowing seller response 1 10 to be created. 

Although the above cryptographic and biometric protocols describe the 
authentication and validation of seller response 1 10, they may be equally applied to the 
authentication and validation of CPO 100, counteroffer 140, buyer response 150, 
purchase confirmation 120, or any other message or communication between buyers, 
30 sellers, and central controller 200. 
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ANONYMOUS TRANSACTIONS EMBODIMENT 
As mentioned previously, the present invention provides for the 
anonymity of both buyers and sellers. Such anonymity is accomplished by eliminating 
all references to the names of the individuals for all transactions. A buyer, for example, 
would include his ID in CPO 100 rather than his name, preventing the seller receiving 
CPO 100 from discovering the buyer's identity. This is desirable if the buyer were a 
biotech firm that did not want rivals to know the type of lab equipment that the 
company was looking for. 

In a similar manner, sellers may also want to keep their identity a secret. 
An airline might not want the public to know that they are heavily discounting fares 
between certain cities. 

Although using ID numbers can provide anonymity, both for buyers and 
sellers, there are a number of potential weaknesses. First, if the database of ID 
numbers, stored in buyer database 255 or seller database 260, and their respective 
15 buyers/sellers is compromised, anonymity is destroyed since the message sender can be 
looked up in buyer database 255 or seller database 260. To prevent this, the ID numbers 
are encrypted with the public key of central controller 200, so that even if it is stolen it 
is useless without the private key. 

Although we have described only one possible method for maintaining 
20 anonymity, there are other equivalents. For example, if the embodiment included 
telephone messaging, the identity of the buyer and seller could be maintained using 
conventional voice modification techniques. If CPO 100 or seller response 1 10 were in 
a paper form, the form could be scanned using optical character recognition and 
translated into digital form, discarding any information that could be found in the 
25 original document. 

TRUSTED SERVER EMBODIMENT 
In one embodiment of the present invention, central controller 200 is 
separated into three distinct elements: operations server 160, trusted server 165, and 
bonding agency 170. Each server performs a distinct task in the process of managing 
30 CPO 100. This separation makes it more difficult for attackers to compromise the 
system, as they must defeat the security of three separate systems instead of one. As 
indicated in Figure 20, these servers work in conjunction with buyer interface 400 and 
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seller interface 300. Operations server 160 has the task of posting CPOs 100, and 
accepts all transactions previously authenticated by trusted server 165. Trusted server 
165 authenticates the identity of buyers and sellers, while bonding agency 170 verifies 
the ability of buyers to pay and the ability of sellers to deliver on bound CPOs 100. In 
this embodiment, each server type may be distributed over a number of servers. 

The following protocols describe the interactions of the three servers and 
assume the following: 

1 . Everyone knows the public keys of operations server 160. trusted 
server 165, and bonding agency 170. 

2. The buyer and potential seller have bond certificates 172, as 
discussed below. 

3. Public keys can be used both for encryption and for signing. 
Before CPO 100 is accepted by operations server 160, it must bear the 

digital signature of both trusted server 165 and bonding agency 170. Because of this, 
15 CPO 100 contains two additional elements - a trusted server ID and a bond certificate. 

The trusted server ED is the ED number of the trusted server 165 that 
authenticated the buyer who created CPO 100. The "bond certificate" is a public key 
certificate, with the certifier (bonding agency 170) specifying a set of valid dates for 
bond certificate 172, a limit to the amount covered, and a set of additional conditions. 
These additional conditions may require on-line checking of a revocation list, may 
specify operations server 160 and trusted server 165 to be used, etc. The private key 
corresponding to the public key certified is not known to bonding agency 170 - only to 
the user. Knowledge of that private key is used as proof of identity for the bondholder. 
(This allows buyer and seller anonymity in many cases, though of course, neither will 
25 be anonymous to bonding agency 1 70 except in very special cases.) 

Bond certificate 172 for the buyer will be referred to as BCB, while the 
corresponding public and private keys will be referred to as PKB and SKB, 
respectively. 

CPO 100 is posted by an interaction between the buyer, trusted server 
30 1 65, and operations server 160. This part of the protocol is possible with nothing more 
than encrypted e-mail transmitted among the parties. 
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Before CPO 100 may be posted, the buyer must get approval from 
trusted server 165. This is required so that both the buyer and operations server 160 
know that trusted server 165 they've designated to decide whether or not the contract 
has been fulfilled is actually willing to accept CPO 100. Operations server 160 will not 
5 accept CPO 100 without a TRUSTED.ACCEPTANCE message as described below. 

The trusted server 165, in turn, will not issue a 
TRUSTED_ACCEPTANCE unless it is convinced that the buyer's CPO 100 is fresh 
(not a replay), and that the buyer's ability to pay is guaranteed by bonding agency 170. 
The buyer must also be convinced that he is being issued a fresh 
] o TRUSTED_ACCEPTANCE. 

The protocol works as follows: 
1 . The buyer forms 

U0 = "REQUEST FOR TRUSTED APPROVAL" 
XO = UO, CPO, RO, Additional Terms 
15 and sends to trusted server 165 

MO = PKEPKA (XO, Sign SKB (XO)). 



2. Trusted server 1 65 responds with 

Ul = "TRUSTED CPO CHALLENGE" 
20 Rl = a 160-bit random number 

XI =U1 hash (XO), Rl 
and sends to the buyer 

Ml = PKEPKB (XI, SignSKA (XI)). 

25 3. The buyer responds to this with 

U2 = "BUYER CPO RESPONSE" 

X2 = U2,hash(Xl) 
and sends to trusted server 165 

M2 = PKEPKA (X2, SignSKB (X2)). 



30 



Trusted server 165 responds with 

U3 = "TRUSTED CPO ACCEPTANCE 1 



41 



WO 98/10361 



PCT/US97/15492 



T3 = Timestamp 
X3 = U3, hash (X2), T3, CPO 
and sends to the buyer 

M3 = PKEPKB (X3, SignSKA (X3)). 
5 5. The buyer stores X3 as TRUSTED_ACCEPTANCE. 

In order for operations server ] 60 to post CPO 1 00, it must be convinced 
that CPO 100 has a fresh TRUSTED.ACCEPTANCE, and that it is guaranteed by 
bonding agency 170. This works as follows: 
10 1. The buyer forms 

R0 = random 1 60-bit number 
U0 = "CPO SERVER SUBMISSION" 
XO = UO, RO, TRUSTED_ACCEPTANCE 
and then sends to operations server 1 60 
15 MO = PKEPKS (XO, SignSKB (XO)). 

2. Operations server 160 receives MO and verifies it. If it's fresh 
(not a replay), and if operations server 160 is willing to post CPO 100, it forms 

Rl = a random 160-bit number 
U 1 = "SERVER CPO CHALLENGE" 
10 XI = l,hash(XO),RI 

and then encrypts and sends to the buyer 

M 1 = PKEPKB (X 1 , SignSKS (X 1 )). 

3. The buyer forms 

U2 = "CPO RESPONSE TO SERVER CHALLENGE" 
!5 and then sends to operations server 1 60 

M2 = PKEPKS (X2, SignSKB (X2)). 

4. If this message's signature verifies properly, then operations 
server 1 60 posts the CPO. Operations server 160 forms 

U3 = "POSTED CPO RECEIPT" 
'0 CPO = U3, hash(X2). CPO. 

It then sends to the buyer 

M3 = PKEPKB (CPO, SignSKS (CPO)). 
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At the end of this protocol, the buyer has a receipt to acknowledge that 
his CPO 100 has been posted, and operations server 160 is convinced that the holder of 
bond certificate 172 has just agreed to CPO 100, and has the approval of trusted server 
165. 

5 The potential seller has a bonding certificate 172 (BCP) of his own. 

Before he is allowed to browse CPOs 100 in real time (with the ability to bind them), he 
must go through a protocol. (CPOs 100 may be available to people who aren't 
browsing, but nobody is allowed to bind CPOs 100 until they go through this protocol.) 
The purpose of this protocol is to prove that the seller is guaranteed by bonding agency 

10 170 to be capable of delivering the required goods, and also to decrease the 
computational load on operations server 160 by establishing a secret authentication key, 
Kp. All of this decreases the computational expense of allowing the potential seller to 
browse CPOs 100. 

1 . The potential seller forms 

15 R0 = a random 1 60-bit number 

T = a time range 

U0 = "REQUEST FOR ACCESS TO BROWSE" 
X0 = U0, RO, T, BCP 
and sends to operations server 160 
20 M0 = PKEPKS (X0, SignSKP (X0)). 

2. Operations server 160 decides whether to grant the potential 
seller access. If so, it forms 

Rl = a random 160-bit number 

Ul = "SERVER BROWSE-ACCESS CHALLENGE" 
25 XI = Ul,hash(X0), Rl 

and sends to the potential seller, 

Ml = PKEPKP(Xl,SignSKS (XI)). 

3. The potential seller responds by forming 

U2 = "BROWSE-ACCESS RESPONSE" 
30 and sends to operations server 160 

M2 = PKEPKS (X2, SignSKP (X2)). 
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forming 



100. 



Operations server 160 verifies the signature, and then responds by 
U3 = "BINDING KEY" 

Kp = a random secret key to be used for binding CPOs 



T = a time range (from first protocol message) 

X3 = U3, hash (X2), T, Kp 
and sends to the potential seller 

M3 = PKEPKP (X3. SignSKS (X3)). 
At the end of this protocol, the potential seller holds the secret shared key 
with which he is allowed to bind CPO 100, within the time limits specified in the last 
message. The potential seller and operations server 160 are both convinced that they 
have interacted with one another in real-time, and operations server 160 knows that the 
potential seller's capacity to deliver on bound CPOs 100 are guaranteed by bonding 
agency 170. 

As the potential seller browses CPOs 100, each is sent to him by 
operations server 160, authenticated under Kp, and including a random challenge to 
prevent replay attacks. When the potential seller wants to bind one, he forms an offer to 
bind CPO 100, and sends it, along with the hash of the authenticated CPO 100, 
authenticated under Kp. Operations server 160 is convinced that this is a valid offer to 
bind CPO 100, and that it's happening in real time. It responds by sending him 
BOUND_CPO. 

1 Operations server 1 60 forms 

U0 = "CPO OFFER" 

R0 = a random- 160-bit number, 

XO = U0, R0, CPO description 
and sends the potential seller 

M0 = PKEPKP (X0, AuthKp(XO)). 
(Note that this step is repeated for each CPO 100 browsed.) 
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2. The potential seller forms 

UI = "CPO OFFER TO BIND" 
R 1 = a random 1 60-bit number 
X I = U 1 , hash (XO), R 1 , Offer Details 
and encrypts and sends to operations server 160 
M 1 = PKEPKS (X 1 , AuthKp(X 1 )). 

3. If the offer is acceptable to operations server 160, then it forms 

U2 = "SERVER BINDING OF CPO" 
T = timestamp 

X2 = U2. hash (XI), BCP, T, CPO, Offer Details and 
encrypts and sends to the potential seller 

M2 = PKEPKP (X2, SignSKS (X2)). 



15 4. The potential seller stores X2, SignSKS (X2) as BOUND_CPO. 

The "Offer Details" field of BOUND.CPO specifics the conditions of 
CPO 100. In most cases, this will involve delivering some goods in exchange for 
payment, possibly in the presence of an agent from trusted server 165. In some cases, 
20 however, this will involve intermediaries, to preserve anonymity for the potential buyer, 
the seller, or both, it is important that the potential seller has the BOUND.CPO so that 
he can prove his identity to the buyer or an intermediary with a simple challenge- 
response protocol. 

This set of protocols describes one possible implementation of an 
25 infrastructure to support CPOs 100. It is important to note that operations server 160. 
trusted server 165, and bonding agency 170 can conceivably be the same entity. In this 
case, these protocols can be dramatically simplified. 

BARTER EMBODIMENT 
Not all transactions require the transfer of money from buyer to seller. In 
30 a barter transaction the distinction between buyer and seller disappears, resulting in a 
contract between a first party and a second party. The first party posts CPO 100, and 
the second party binds it. Instead of getting cash, the second party receives goods from 
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the first party. A first party who wanted to get rid of a motorcycle, for example, could 
post CPO 100 in which he offered to exchange the motorcycle for a first class ticket 
from New York to London. 

ARBITRATION PROTOCOLS 
5 Although the previous embodiments have described the delivery of 

goods from seller to buyer as the end of the process, there will inevitably be disputes 
arising from some transactions, requiring follow-up activity to resolve these disputes. 
The present invention can support dispute resolution in two ways. 

First, language can be built into every CPO 100 requiring that both 

10 parties submit to binding arbitration of all disputes, helping to avoid more costly and 
time consuming legal battles in a court of law. Additionally, liquidated damages may 
be set which specify damage amounts for particular infractions of CPO 100. 

Second, central controller 200 can support the arbitration process by 
providing an arbiter for each dispute. Such arbitration might be required when goods 

15 shipped from the seller do not correspond to the conditions of CPO 100. A buyer 
seeking a non-stop airline ticket, for example, might seek damages against a seller who 
delivered a ticket with one or more stops. Similarly, a business traveler whose CPO 100 
for a non-smoking hotel room might seek damages from the hotel which bound the CPO 
with a smoking room. Instead of seeking damages, the buyer may seek replacement of 

20 the goods, such as another airline ticket that was non-stop. In an arbitration involving 
airline tickets, the buyer may submit a copy of the ticket to central controller 200 along 
with the tracking number of CPO 100, allowing the arbiter to establish whether or not 
the seller fulfilled the conditions of CPO 100. Sellers may also initiate arbitration 
proceedings if they have shipped the goods and have not yet received payment from the 

25 buyer. 

In an alternative embodiment, transaction data can be sent to third party 
arbiters outside the system. Central controller 200 may send a copy of CPO 100, seller 
response 1 10, and purchase confirmation 120 to the arbiters. Cryptographic keys may 
also be provided to the arbiters if there are questions of authenticity or non -repudiation. 
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APPLICATIONS OF THE INVENTION 
In order to clarify the application of the present invention, the following 
examples demonstrate potential needs of end users: 
CPO: Airline tickets 
5 Four tickets needed 

From Chicago, OHare or Midway to Phoenix. 
Leaving on April 12 or 13 
Returning on April 18 or 19. 
Any of the six largest carriers acceptable. 
10 Change of planes is acceptable if layover is less than 2 hours. 

Ill bind at $180 per ticket, excluding tax. 
CPO: Hotel accommodations 
Five nights lodging 

Arrive April 12 or 13, Depart April 18 or 19 
15 Within 30 minutes drive time of downtown Phoenix. 

Double bed 
Non-smoking 

Hotels, motels or bed & breakfasts are acceptable 

Must be AAA approved or Mobil 2* or better. 
20 111 bind at $55 per night (excluding tax). 

CPO: New car purchase 

1997 Ford Taurus 

Must be in dealer stock 

GL package w/air conditioning 
25 AM/FM/Cassette (Stock #1 224-099) 

May have other options already installed 

Can be white, tan, green or maroon 

Must have 100 miles or less, never titled. 

No dealer demo cars 
30 Delivered to me no later than July 15, 1996 

Loan pre-approval: Chase Manhattan #1 220-998-887 AD-21 

111 bind at $21,350 
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CPO: Car insurance 

1997 Ford Taurus 

1 driver, age 40, male 

Reside in Ridgefield, CT 

Drive to work 30 miles 

Collision included 

$500 deductible 

Glass coverage included 

No speeding infractions in last 3 years 

No accident in past 3 years 

1MM liability umbrella 

Driver's license # CT 1222-221-2298 

Carrier must be rated A or better by AM Best. 

Ill bind at $1,200 per year 
CPO: U.S. silver dollars 

1886 Morgan 

Philadelphia mint mark 

Sealed in ANA packaging 

MS94 or better grade 

I will purchase up to 6 total 

Sellers may fulfill all or part of order 

111 bind at $225 each 

Offer Administrator; Coinworld, P.O. Box 1000, N.Y., N.Y. 
Mr. K.Smith 212-222-1000 
CPO; Industrial commodity 

My company wants to purchase 40 tons of steel 
Grade 120 

Delivered FOB to NY, NY 
Class 4 Slabs or Class 12 ingots 
Alloy RT- 12 or equivalent 
Deliver by August 1, 1996 
Maximum price known to Citibank 
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First bid below maximum will bind 
Citibank to provide instant price verification 
1 bid per supplier per day (GMT) 
E-mail @ metals.biddesk4022Citi.com 
Letter of Credit payment, Citibank 100-887-9877 
CPO: Credit Card Application 
VISA Gold Card 
Credit line $5,000 
Interest rate 1 2% or lower 
III bind at $10 per year 

Financial history available at http:y/www.provider/-shapiro23 
CPO: Reward for Return 

Briefcase lost with important computer disks inside 
Disks labeled RT-554 IBM 
Case is brown leather, brass snaps, RL monogram 
Left on NYC subway, April 7, 1996 F Train. 
Ill bind at $500 

Provide lost & found receipt # to claim reward 
Offer Administrator: NYC Police Lost & Found 
Mr. K.Smith 212-555-1000 



INDUSTRIAL APPLICABILITY 
In view of the foregoing detailed description, it is evident that the instant 
invention may be used to create one or more of the following systems, among others: 

- a system which allows a seller to meet the terms of the purchase offer 
to bind the buyer to accept the seller's fulfillment of that offer; 

- a system which allows the seller to be able to collect funds immediately 
upon his acceptance of the buyer's terms as set forth in the purchase offer; 

- a system that allows for a trusted third-party administrator whose 
decision regarding the fulfillment, adequacy or interpretation of any aspect of the 
process shall be binding on the parties; 
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- a system which allows the seller to receive part of his payment upon 
agreeing to the buyer's purchase offer, and a subsequent payment upon delivery of the 
goods or services called for in the buyer's purchase offer; 

- a system which allows either buyers or sellers to remain anonymous up 
5 until such time as an agreement is consummated and for buyers to remain anonymous 

even after the agreement is consummated by using the trusted third-party as a relay 
system for delivery of goods or services called for by the buyer's purchase offer; 

- a system which ensures that buyers using the inventive system are not 
inundated with inquiries or acceptances from unqualified sellers; 

10 - a system which provides a system in which the identity of the buyer is 

authenticated along with the integrity of the buyer's purchase offer. 

- a system in which the identity of the seller is authenticated in order to 
determine the seller's capacity to satisfy the conditions of the purchase offer; 

- a system which allows sellers to submit authenticatablc counteroffers to 

15 the buyer; 

- a system in which counteroffers may allow the buyer to bind the seller 
to the counteroffer, subject to the authenticatable terms of that counteroffer; 

- a system which allows for delivery of digitally-based products such as 
certificates of insurance from the seller to the buyer according to the terms of the 

20 buyer's purchase offer and the cryptographic validation of such delivery; 

- a system which allows for purchase offers where more than one seller 
may bind the buyer to the purchase offer; and 

- a system which shows how all or part of the system can be practiced 
using non-electronic means such as printed media or advertisements in newspapers. 

25 In view of the aforementioned detailed description of ihe present 

invention, it is readily apparent that the present invention provides a method and 
apparatus for prospective buyers of goods or services to communicate a binding 
purchase offer globally to potential sellers, for sellers conveniently to search for 
relevant buyer purchase offers, and for sellers to bind a buyer to a contract based on the 

30 buyer's purchase offer. Additionally, the present invention can effectuate performance 
of the agreement between the buyer and seller by guaranteeing buyer payment for the 
purchase. The present invention is therefore a highly effective bilateral buyer-driven 



50 



WO 98/10361 



PCTYUS97/15492 



commerce system which improves the ability of buyers to reach sellers capable of 
satisfying the buyer's purchasing needs and improves sellers' ability to identify 
interested buyers. 

In one embodiment of this invention, communications between buyers 
5 and sellers are conducted using an electronic network and central controller. A buyer 
who wishes to make a purchase accesses the central controller located at a remote 
server. The buyer will then create a conditional purchase offer ("CPO") by specifying 
the subject of the goods he wishes to purchase, a description of the goods he wishes to 
obtain, and any other conditions the buyer requires. For example, a typical CPO could 

10 specify that the buyer wants to purchase a block of four airline tickets from Chicago's 
OHare Airport to Dallas, Texas, the tickets must be from any of the six largest U.S. 
carriers, the buyer is willing to change planes no more than once so long as the 
scheduled layover is less than two hours, and the buyer is willing to pay $180 per ticket, 
plus any applicable taxes. 

15 The buyer then attaches a user identification to the CPO and transmits 

the CPO to the central controller. Under the present invention, the CPO may be 
transmitted via numerous means including a world-wide-web interface, electronic mail, 
voice mail, facsimile, or postal mail. Standard legal provisions and language are then 
integrated with the CPO to "fill in the gaps" of the buyer's purchase offer. Alternatively, 

20 the CPO may be developed while the buyer is on-line with the central controller. 

Before communicating the CPO to potential sellers, the central controller 
authenticates the buyer's identification number against a buyer database. The central 
controller may require that the buyer provide a credit card number and may also ensure 
that the buyer has sufficient credit available to cover the purchase price specified in the 

25 CPO by contacting the credit card clearinghouse. The central controller then assigns a 
unique tracking number to the CPO and globally displays the CPO in a manner such 
that it is available to be viewed by any interested potential sellers. CPOs may be 
displayed by subject category to make it easier for potential sellers to identify relevant 
CPOs. Thus, a seller could log onto a web-site, for example, and see a listing of CPO 

30 subject categories. The seller could then choose a particular subject and have the ability 
to browse CPOs which correspond to that subject category. In one embodiment, the 
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seller may be required to provide qualifications in order to view the CPOs of a given 
subject category. 

If, after reviewing a particular CPO, a potential seller wishes to accept 
the CPO the seller communicates his intent to the central controller. The central 
5 controller then timestamps the message from the seller and authenticates the identity of 
the seller and his capacity to deliver the goods sought by the buyer. The system then 
verifies that the particular CPO is still "active" and capable of being accepted. If a CPO 
is capable of being accepted only by one seller, it is "completed" when the first qualified 
seller accepts it. Subsequent sellers will not be able to accept a "completed" CPO. If a 

10 seller accepts an active CPO, a unique tracking number is assigned to the seller's 
acceptance. The acceptance is then stored in a database. The buyer and seller are now 
parties to a legally binding contract. 

In another embodiment, the central controller manages the payment 
system between the buyer and seller automatically. Various methods of payment may 

15 be utilized by the invention, including credit cards, personal checks, electronic funds 
transfer, debit cards, and digital cash. The payment system may also involve the use of 
an escrow account associated with the buyer wherein funds advanced by the buyer to 
cover the purchase of a desired good can be kept pending acceptance by a qualified 
seller. Moreover, the timing of payment to the seller can be varied. The seller can be 

20 paid immediately after the seller accepts the CPO or payment can be delayed until after 
the seller performs his obligations under the contract. 

In yet another embodiment of the present invention, a seller is given the 
option to respond to a CPO by issuing a binding counteroffer with conditions different 
from the original CPO. The seller transmits the counteroffer to the central controller 

25 that then forwards the counteroffer to the buyer. The buyer is then given the option of 
accepting the counteroffer and thereby binding the seller to a contract. 

The present invention can also be practiced in off-line embodiments. 
Instead of using electronic mail or web-based servers, buyers and sellers may 
communicate with the central controller via telephone, facsimile, postal mail, or another 

30 off-line communication tool. For example, buyers may use telephones to create CPOs 
(with or without the assistance of live agents) and potential sellers may use a telephone 
to browse and bind CPOs. 
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In another on-line embodiment, cryptographic protocols are used to 
authenticate the identity of buyers and/or sellers and verify the integrity of buyer and 
seller communications with the central controller. Using cryptography and biometrics, 
the central controller can make it significantly more difficult for unauthorized persons to 
5 tamper with the system by passing themselves off as legitimate buyers or sellers or 
eavesdropping on system communications. 

Anonymity is another advantage of the present invention. For numerous 
privacy and competitive reasons, buyers and sellers often prefer not to have their 
identities revealed to the general public when engaging in commercial transactions. The 
10 present invention effectuates the anonymity of buyers and sellers through the use of 
identification numbers stored in a database secured by the central controller. 

One embodiment of the present invention divides the functionality of the 
central controller into three components and embodies them in three separate servers: an 
operations server, a trusted server, and a bonding agency. The trusted server 
15 authenticates the identity of buyers and sellers while the bonding agency verifies their 
ability to pay or deliver goods. The operations server posts the CPO, relying upon 
messages from the other two servers for validation. This configuration allows for 
greater specialization of the servers. 

Another embodiment of the present invention does not require a transfer 
20 of money from a buyer to a seller. Instead, the system may be used to consummate a 
contract involving an exchange of goods, services, or other non-monetary consideration. 

Finally, an embodiment of the present invention includes a mechanism 
for resolving disputes between buyers and sellers arising out of agreements 
consummated using the system. The parties may be required in CPOs to stipulate to 
25 binding arbitration and may be assisted jn the arbitration process by the central 
controller. The central controller may serve as an arbitrator or may refer the dispute to a 
third-party arbitrator for resolution. 

What the present invention accomplishes, which no previous system has 
done before, is literally to hang buyer money out on a clothesline for all sellers to see. 
30 Attached to the money is a note describing what the seller has to agree to do in order to 
take the money down off the clothesline. There is no uncertainty or waste of time on 
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the part of the seller. He knows that if he can meet the conditions set forth by the buyer, 
he can immediately close the sale and get paid for it. No hassles. No negotiations. 

The invention also allows buyers to reach a large number of remotely 
located sellers who normally would not be able to afford to find the buyer, but who may 
5 be able to provide the buyer with the exact deal the buyer desires. For instance, this 
might be the case for a car buyer who could precisely define the car and option 
packages he wanted for a specified price. The present invention allows such a buyer to 
issue a binding purchase offer that is globally communicated to authorized dealers in the 
U.S.. Any one of those dealers could then decide whether or not to accept the offer. 

10 The buyer's advantage is particularly significant when the sellers of products sought by 
the buyer have no inventory carrying costs, as is the case with insurance sales. 
Insurance buyers could use the present invention to cast a wide net to reach thousands 
of potential insurance sellers and potentially find a seller willing to satisfy the buyers 
specified purchase conditions. 

15 It is a goal of the present invention to provide a robust system that 

matches buyers' requirements with sellers capable of satisfying those requirements. The 
invention provides a global bilateral buyer-driven system for creating binding contracts 
incorporating various methods of communication, commerce and security for the buyer 
and the seller. The power of a central controller to field binding offers from buyers, 

20 communicate those offers globally in a format which can be efficiently accessed and 
analyzed by potential sellers, effectuate performance of resulting contracts, resolve 
disputes arising from those contracts, and maintain billing, collection, authentication, 
and anonymity makes the present invention an improvement over conventional systems. 

AGENCY-BASED SELLERS 

25 The method and apparatus of another embodiment of the present 

invention, which permits the CPO management system to accept or reject a given CPO 
on behalf of certain agency-based sellers who have delegated such authority to the CPO 
management system, will now be discussed with reference to Figures 21 through 40. 
Figure 21 shows a conditional purchase offer (CPO) management system 2100 for 

30 receiving conditional purchase offers from one or more customers or travel agents 2110, 
hereinafter referred to as customer 2110, and for evaluating the received CPOs against a 
number of CPO rules defined by a plurality of sellers, such as airlines 2120, 2130 or 
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cruise operators (not shown), to determine whether any seller is willing to accept a 
given CPO. As discussed further below, if a seller accepts a given CPO, the CPO 
management system 2100 binds the customer 2110 on behalf of the accepting seller 
2130, to form a legally binding contract. 
5 As used herein, a CPO is a binding offer containing one or more 

conditions submitted by a customer 21 10 for the purchase of an item, such as air travel, 
at a customer-defined price. In the illustrative airline embodiment, the customer- 
defined conditions would include itinerary parameters, such as the origin and 
destination cities; acceptable dates and times of departure and return; and whether 

10 connecting flights or stopovers are acceptable to the customer. In addition, the 
parameters of a CPO may allow a customer to specify one or more preferred airline(s), 
flights, seat assignments, seat class, aircraft type, refund/change rules, or maximum 
layover time. In a cruise embodiment, the customer-defined conditions would also 
include itinerary parameters, such as the origin and destination cities; acceptable dates 

15 and times of departure and return; as well as one or more preferred cruise operators, 
ship type, cabin class, and dining preference. 

As discussed further below, a CPO rule is a set of restrictions defined by 
a given seller, such as an airline, to define a combination of such restrictions for which 
the seller is willing to accept a predefined minimum price. In a preferred embodiment, 

20 the CPO rules are generated by the revenue management system 2500 of the respective 
airline or cruise operator. In alternate embodiments, the CPO rules may be generated by 
a yield management system, a profit management system, or any system that controls 
and manages inventory. 

As discussed more fully below in conjunction with Figures 25b and 39, 

25 the revenue management system 2500 will employ a CPO rules generation process 3900 
to generate CPO rules by evaluating current inventory, pricing and revenue information, 
as well as historical patterns and external events, to forecast future travel. Thereafter, 
the CPO rules are utilized by the CPO management system 2100 to render a decision to 
either accept, reject or counter a CPO on behalf of a particular airline or cruise operator. 

30 According to a feature of the present invention, the CPO rules are dynamic in nature and 
may be updated by a given airline or other seller, as necessary. 
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For example, a CPO rule for a given airline can specify that the airline 
will accept any CPO for travel between Newark, New Jersey (EWR) and Orlando, 
Florida (MCO) during the month of October, 1997, provided that (i) the customer 
travels between Tuesday and Thursday, (ii) the tickets are booked within 21 days of 

5 departure, (iii) the price is at least $165 per ticket, (iv) K-class inventory is available on 
all flight segments of the customer's itinerary, and (v) there are at least two (2) 
passengers travelling together. 

Although the CPO management system 2100 is illustrated herein as a 
system for selling airline or cruise tickets, the CPO management system 2100 could be 

10 utilized to sell any good or service product, such as automobiles, insurance, computer 
equipment, or hotel accommodations, as would be apparent to a person of ordinary skill. 
For a more detailed discussion of a general CPO management system for selling such 
items, see U.S. Patent Application Serial No. 08/707,660, filed September 4, 1996, the 
parent application to the present invention, which is incorporated by reference herein. It 

15 is noted that in such alternate embodiments, the revenue management system 2500, 
discussed below in conjunction with Figures 25a through 25c, may be embodied as an 
inventory management system or any other system utilized by the seller to establish 
pricing and inventory information for the respective item. 

CPO MANAGEMENT SYSTEM 

20 As shown in Figure 21, the CPO management system 2100 preferably 

includes a CPO management central server 2200 and one or more secured airline 
servers 2300. As discussed further below in conjunction with Figure 23, each secured 
airline server 2300 may be associated with one or more airlines or cruise operators and 
each server 2300 stores, among other things, the CPO rules defined by any associated 

25 sellers, such as the airline 2120. Each secured airline server 2300 may be remotely 
located from the CPO management central server 2200, as shown in Figure 21, or may 
be integrated with the CPO management central server 2200. In one remote 
embodiment, the secured airline server 2300 associated with each airline or cruise 
operator may be physically located at a processing facility secured by the particular 

30 airline or cruise operator, or at the physical location of a third party. In this manner, the 
airline or cruise operator can evaluate CPO rules independently. 
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The particular location of the secured airline servers 2300 will dictate the 
nature of the information that is transmitted between the airlines 2120, 2130 or cruise 
operators (not shown) and the CPO management system 2100, as would be apparent to 
a person of ordinary skill. For example, if the secured airline servers 2300 are 
5 integrated with the CPO management central server 2200, or are otherwise remotely 
located from the respective airlines 2120, 2130 or cruise operators (not shown), then the 
respective airline 2120, 2130 or cruise operator will transmit the CPO rules to the 
location of the airline's associated secured airline server 2300 for storage of the CPO 
rules and application of the CPO rules against each received CPO. Likewise, if the 

10 secured airline servers 2300 are physically located at the processing facility secured by 
the associated airline or cruise operator, then the CPO management central server 2200 
will transmit the CPOs to each airline or cruise operator for processing and the airlines 
or cruise operator will return the response for each CPO to the CPO management central 
server 2200. Thus, the CPO management system 2100 can determine if one or more 

15 sellers accepts a given CPO by providing the CPO to each seller and receiving an 
acceptance or rejection, or by applying the CPO to the CPO rules to render a decision to 
either accept, reject or counter a CPO on behalf of a particular seller. 

The CPO rules contain sensitive information, including price flexibility 
and available capacity, which, if known to a seller's competitors or customers, could 

20 dramatically impact the seller's overall revenue structure. Thus, according to a feature 
of the present invention, the CPO rules are preferably securely stored by each airline 
server 2300, if necessary, to prevent one seller, such as airline 2120, from accessing, 
obtaining or altering the CPO rules of another seller, such as airline 2130. In one 
embodiment, the secured airline servers 2300 utilize computer security techniques, such 

25 as database access control mechanisms. In this manner, the integrity and confidentiality 
of the CPO rules are maintained in the potentially hostile computing environment. 

In addition, according to a further feature of the invention, the CPO 
management system 2100 prevents customers 2110 from submitting multiple CPOs 
containing a progressively increasing price in order to identify the seller's defined 

30 minimum price for a given flight or berth. For example, if the CPO will be binding 
upon the customer 21 10 if accepted by any airline 21 20 or cruise operator, the customer 
2100 will be discouraged from "pinging" the CPO management system 2100 to identify 
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the seller's underlying price flexibility. In addition, the CPO management system 2100 
can limit the number of CPOs that any customer 21 10 can submit within a predefined 
time period. 

In alternate embodiments, the customer or travel agent 2110 can be 

5 charged a fee or a penalty if a ticket is not booked when at least one airline has accepted 
the CPO or the CPO management system 2100 can evaluate a rating of said customer 
2110 containing information regarding the likelihood that said customer 21 10 will book 
a ticket corresponding to said CPO. For a more detailed description of a suitable rating 
system, see U.S. Patent Application Serial No. 08/81 1,349, filed March 4, 1997, entitled 

10 AIRLINE PRICE INQUIRY METHOD AND SYSTEM, assigned to the assignee of the 
present invention and incorporated by reference herein. In one embodiment, the 
evaluated rating comprises a ratio of bookings to purchase offers by the customer 2110. 
In this manner, the airline or cruise operator can be confident that if the seller accepts 
the customer's offer, the customer will book the ticket without using the information to 

15 ascertain the seller's underlying level of price flexibility. The particular location of a 
given secured airline server 2300 may also impact the level of security measures that the 
associated airline(s) or cruise operator(s) may desire for the sensitive CPO rules. For 
example, if a given secured airline server 2300 is dedicated to a single airline and is 
physically located at a processing facility secured by the associated airline, then the 

20 respective airline may implement its own minimal security measures to control the 
processing of each CPO against its own CPO rules, if desired, and thereby maintain the 
integrity and confidentiality of the price-sensitive information incorporated into the 
CPO rules. If, however, a given secured airline server 2300 stores the CPO rules for a 
plurality of airlines or cruise operators and is remotely located from such airlines or 

25 cruise operators, then the importance of implementing computer security and database 
access control mechanisms may be increased, as would be apparent to a person of 
ordinary skill. 

As discussed further below, each customer 2110 contacts the CPO 
management system 2100, for example, by means of telephone, facsimile, online access, 
30 e-mail, in-person contact or through a travel agent, and provides the CPO management 
system 2100 with the terms of their CPO. It is noted that each customer 2110 may 
employ a general -purpose computer for communicating with the CPO management 
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system 2100, The general-purpose computer of each customer 2110 is preferably 
comprised of a processing unit, a modem, memory means and any software required to 
communicate with the CPO management system 2100. 

Once the terms of the CPO have been received by the CPO management 

5 system 2100, the CPO management central server 2200 will execute a CPO 
management process 3600, discussed below in conjunction with Figures 36a through 
36c, to compare the received CPO against the CPO rules of each airline or cruise 
operator. As a result of this comparison, the CPO is either accepted, rejected or 
countered. Thereafter, the customer 2110 is notified of the response of the airlines or 

10 cruise operators to the CPO. If a seller accepts the CPO, or if the customer 2110 
accepts a counteroffer from a seller, a ticket is then booked by the CPO management 
system 2100 with the appropriate restrictions which meet the conditions defined by the 
customer 21 10. 

According to a further feature of the present invention, the minimum 

15 requirements of a CPO are designed to discourage utilization of this system by business 
travelers or last minute travelers who are typically willing to pay full-fare. For example, 
business travelers will be discouraged if the CPO rules require a Saturday night stay or 
significant flexibility by the customer 21 10 on the time of both the departure and return 
portions of the customer's itinerary. In this manner, business travelers, who are 

20 typically unwilling to lose up to a full day at either end of their trip, will be discouraged 
from purchasing such discounted tickets. Thus, the present invention permits airlines to 
fill otherwise empty seats in a manner that stimulates latent and unfulfilled leisure travel 
demand while leaving underlying fare structures of the airlines 2120, 2130 intact. 

Likewise, in embodiments where the CPO management system is 

25 utilized for the sale of any item, the minimum requirements of a CPO are preferably 
designed to discourage utilization of this system by customers who are typically willing 
to pay the full retail price. For example, when selling fashion items, CPO customers 
can be required to purchase fashions from the previous season. Similarly, the CPO rules 
can be designed to require the purchase of multiple quantities of a given item, and 

30 thereby discourage use by consumers looking for one item, who are more likely to pay 
the full retail price. 
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In a preferred embodiment, the CPO management system 2100 may 
optionally access a central reservation system (CRS) 2400, discussed below in 
conjunction with Figure 24, to perform itinerary queries that will identify particular 
flights or berths which satisfy a given itinerary, and to make reservations. The central 
5 reservation system (CRS) 2400 may be embodied, for example, as an existing 
conventional reservation system, such as Apollo, Sabre, System One or Worldspan. 

In addition, the CPO management system 2100 could alternatively access 
the proprietary reservation systems (ARSs) 2150 of each airline or cruise operator to 
perform such itinerary queries and to make reservations with the respective airline or 
10 cruise operator. The airline reservation systems (ARSs) 2150 maintained by each 
airline 2120, are each essentially a subset of the central CRS 2400. Thus, in view of the 
overlapping functions and capabilities of the CRS 2400 and the proprietary reservation 
systems 2150 of each airline or cruise operator, the CPO management system 2100 
could access any of such systems to obtain required information, and the terms "CRS" 
15 and "ARS" are used interchangeably herein. 

As shown in Figure 21, each airline 2120, 2130 or cruise operator (not 
shown), also has a revenue management system (RMS) 2500, discussed further below in 
conjunction with Figures 25a through 25c. The RMS 2500 may be embodied as a 
conventional RMS, as modified herein to generate CPO rules and to otherwise allocate 
20 and price airline or cruise tickets for sale to CPO customers. 

Generally, the revenue management systems (RMSs) 2500 are utilized to 
optimize revenue per flight or berth, in a known manner. An RMS performs seat or 
cabin inventory control by periodically adjusting nested booking limits ("buckets") for 
the various fare classes, in order to optimize the passenger mix and thereby maximize 
25 the generated revenue. 

The CPO management system 2100, customer 21 10, airlines 2120, 2130, 
cruise operators (not shown) and central reservation system 2400 (collectively, the 
"nodes") preferably transmit digitally encoded data and other information between one 
another. The communication links between the nodes preferably comprise a cable, fiber 
30 or wireless link on which electronic signals can propagate. For example, each node may 
be connected via an Internet connection using a public switched telephone network 
(PSTN), such as those provided by a local or regional telephone operating company. 
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Alternatively, each node may be connected by dedicated data lines, cellular. Personal 
Communication Systems ("PCS"), microwave, or satellite networks. 

Figure 22 is a block diagram showing the architecture of an illustrative 
CPO management central server 2200. The CPO management central server 2200 
preferably includes certain standard hardware components, such as a central processing 
unit (CPU) 2205, a random access memory (RAM) 2210, a read only memory (ROM) 
2220, a clock 2225, a data storage device 2230, and communications ports 2240, 2250, 
2260. The CPU 2205 is preferably linked to each of the other listed elements, either by 
means of a shared data bus, or dedicated connections, as shown in Figure 22. 

The CPU 2205 may be embodied as a single commercially available 
processor, such as Intel's Pentium 100 MHz P54C microprocessor, Motorola's 120 MHz 
PowerPC 604 microprocessor or Sun Microsystem's 166 MHz UltraSPARC-I 
microprocessor. Alternatively, the CPU 2205 may be embodied as a number of such 
processors operating in parallel. 

The ROM 2220 and/or data storage device 2230 are operable to store one 
or more instructions, discussed further below in conjunction with Figure 36, which the 
CPU 2205 is operable to retrieve, interpret and execute. For example, the ROM 2220 
and/or data storage device 2230 preferably store processes to accomplish the transfer of 
required payments, charges and debits, between the airlines 2120, 2130 and customers 
2110. In particular, as discussed below in conjunction with Figure 36c, the CPO 
management process 3600 preferably transmits the credit card information associated 
with a given customer 21 10 to the credit card issuer for payment, if a ticket is actually 
issued to the customer 2110. The processing of such accounting transactions are 
preferably secured in a conventional manner, for example, using well-known 
cryptographic techniques. 

The CPU 2205 preferably includes a control unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as, for example, a stackable 
cache or a plurality of registers, in a known manner. The control unit is operable to 
retrieve instructions from the data storage device 2230 or ROM 2220. The ALU is 
operable to perform a plurality of operations needed to carry out instructions. The CPU 
local memory storage device is operable to provide high-speed storage used for storing 
temporary results and control information. 
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As discussed further below in conjunction with Figures 26 through 29, 
respectively, the data storage device 2230 includes a customer database 2600, an airline 
database 2700, a flight schedule database 2800, and a CPO database 2900. The 
customer database 2600 preferably stores information on each customer of the CPO 
5 management system 2100, including biographical information and billing information, 
such as a credit card number. The airline database 2700 preferably stores information 
on each airline which is registered with the CPO management system 2100 to sell 
airline tickets to CPO customers, including address and contact information. The flight 
schedule database 2800 preferably stores specific flight information for each O & D 
10 Pair. Finally, the CPO database 2900 preferably contains a record of each CPO being 
processed by the CPO management system 2100, including the terms of the CPO and 
the associated status. 

In addition, the data storage device 2230 includes a CPO management, 
process 3600, discussed further below in conjunction with Figure 36. Generally, the 
15 CPO management process 3600 receives each CPO from a customer 2110, compares 
the CPO against the CPO rules of each airline 2120, 2130, and determines whether to 
accept, reject or counter the CPO on behalf of an airline. 

The communications port 2240 connects the CPO management central 
server 2200 to the central reservation system (CRS) 2400 and the proprietary 
20 reservation systems (ARSs) 2150 maintained by each airline 2120, 2130. The 
communications port .2250 connects the CPO management central server 2200 to 
individual customers and travel agents, such as the customer 2110, for example, by 
means of an Internet connection using the public switched telephone network (PSTN). 
The communications port 2260 connects the CPO management central server 2200 to 
25 any remote secured airline servers 2300. The communications ports 2240, 2250, 2260 
each preferably include multiple communication channels for simultaneously 
establishing a plurality of connections. It is noted that although the CPO management 
central server 2200 is illustrated as having three separate communication ports 2240, 
2250, 2260, the CPO management central server 2200 could alternatively be 
30 implemented with a single connection to an Ethernet network, which in turn provides 
the central server 2200 with a connection to the various nodes. 
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Figure 23 is a block diagram showing the architecture of an illustrative 
secured airline server 2300. As previously indicated, the CPO management system 
2100 may utilize one or more secured airline servers 2300, each supporting one or more 
airlines 2120, 2130. Each secured airline server 2300 preferably includes certain 
standard hardware components, such as a central processing unit (CPU) 2305, a random 
access memory (RAM) 2310, a read only memory (ROM) 2320, a clock 2325, a data 
storage device 2330, and communications ports 2340, 2345. Each of these components 
may be identical to those described above in conjunction with Figure22. 

As previously indicated, in one embodiment, the CPO rules may be 
stored in a secure database to maintain the integrity and confidentiality of the highly 
sensitive information included in each CPO rule. Thus, the secured airline server 2300 
preferably uses a secure database, such as the products commercially available from 
Oracle, Informix or IBM. 

As discussed further below in conjunction with Figures 30 through 32, 
respectively, the data storage device 2330 includes a secured airline rules database 
3000, a counteroffer rules database 3100, and a secured airline audit database 3200. 
The secured airline rules database 3000 preferably maintains the CPO rules for the one 
or more airlines associated with the secured airline server 2300. The counteroffer rules 
database 3100 is preferably stored by each secured airline server 2300 to maintain a set 
of tolerances which may be utilized by the CPO management system 2100 to generate a 
counteroffer to a CPO on behalf of an airline, if the CPO is within predefined tolerances 
of one or more restrictions associated with a given CPO rule. As previously indicated, 
the secured airline rules database 3000 and the counteroffer rules database 3 100 may be 
stored in an encrypted format to maintain the integrity and confidentiality of the highly 
sensitive information included in the CPO rules. The secured airline audit database 
3200 preferably maintains an audit trail for each CPO that is processed by the CPO 
management system 2100. 

In addition, the data storage device 2330 includes an evaluation process 
3700 and an audit process 3800, discussed further below in conjunction with Figures 37 
and 38, respectively. Generally, the evaluation process 3700 is a subroutine executed 
by the CPO management process 3600, which receives a CPO and compares the CPO 
against the rules of one airline, such as the airline 2120, to generate a response on behalf 
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of the airline to the given CPO. The audit process 3800 is a subroutine executed by the 
CPO management process 3600 to maintain an audit trail for each CPO that is processed 
by the CPO management system 2100. 

The communications port 2340 connects the secured airline server 2300 
to the CPO management central server 2200. The communications port 2345 connects 
the secured airline server 2300 to the associated airlines(s) 2120. The communications 
ports 2340, 2345 preferably include multiple communication channels for 
simultaneously establishing a plurality of connections. 

CENTRAL RESERVATION SYSTEM 

Figure 24 is a block diagram showing the architecture of an illustrative 
central reservation system (CRS) server 2400. The CRS 2400 preferably includes 
certain standard hardware components, such as a central processing unit (CPU) 2405, a 
random access memory (RAM) 2410, a read only memory (ROM) 2420, a clock 2425, a 
data storage device 2430, and a communications port 2440. Each of these components 
may be identical to those described above in conjunction with Figure 22. 

The ROM 2420 and/or data storage device 2430 are operable to store one 
or more instructions, for processing (1) flight information received from the airlines; (2) 
itinerary inquiries regarding flight availability; and (3) ticket bookings, in a known 
manner, which the CPU 2405 is operable to retrieve, interpret and execute. 

As discussed further below in conjunction with Figures 28, 33 and 34, 
respectively, the data storage device 2430 includes a flight schedule database 2800, a 
pricing and restrictions database 3300, and a seat allocation database 3400. As 
previously indicated, the flight schedule database 2800 contains essentially the same 
flight information as the database of the same name which is stored by the CPO 
management central server 2200, namely, specific flight information for each O & D 
Pair. The pricing and restrictions database 3300 maintains pricing information and 
related restrictions for each fare class on a given flight offered by the airlines 2120, 
2130. The seat allocation database 3400 maintains available inventory information for 
each fare class on a given flight offered by the airlines 2120, 2130. 

The communications port 2440 connects the CRS 2400 to the CPO 
management central server 2200 and to each airline, such as the airlines 2120, 2130. 
The CRS 2400 preferably includes an electronic mail processor 2450 for processing and 
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storing e-mail messages transmitted between the CRS 2400 and the various customers 
2110, airlines 2120, 2130 and the CPO management system 2100. 

REVENUE MANAGEMENT SYSTEM 
Figure 25a is a block diagram showing the architecture of an illustrative 
5 revenue management system (RMS) 2500, as maintained by each airline, such as the 
airline 2120. As previously indicated, the RMS 2500 may be embodied as a 
conventional RMS, such as an RMS commercially available from Sabre Decision 
Technologies, as modified herein to generate CPO rules and to otherwise allocate and 
price airline tickets for sale to CPO customers. In this manner, the RMS 2500 makes a 

10 portion of the inventory of an airline 2120 available for sale to CPO customers 2110. It 
is noted that the RMS for many airlines performs only the function of inventory 
allocation and does not incorporate a pricing function. In such cases, a separate system, 
such as a manual process, is utilized to price inventory that has been allocated by the 
RMS. In the illustrative embodiment disclosed herein, the RMS 2500 performs both the 

15 inventory allocation and pricing functions. 

The RMS 2500 preferably includes certain standard hardware 
components, such as a central processing unit (CPU) 2505, a random access memory 
(RAM) 2510, a read only memory (ROM) 2520, a clock 2525, a data storage device 
2530, and a communications port 2540. Each of these components may be identical to 

20 those described above in conjunction with Figure 22. 

The ROM 2520 and/or data storage device 2530 are operable to store one 
or more instructions, for analyzing current seating inventory and revenue, as well as 
historical patterns, to allocate and price available seat inventory in an effort to maximize 
revenue for the airline, which the CPU 2405 is operable to retrieve, interpret and 

25 execute. 

As discussed further below in conjunction with Figures 33 through 35, 
respectively, the data storage device 2530 includes a pricing and restrictions database 
3300, and a seat allocation database 3400, which each contain essentially the same 
information as the databases of the same name stored by the CRS 2400, as well as a 
30 forecast and demand analysis database 3500. As previously indicated, the pricing and 
restrictions database 3300 maintains pricing information and related restrictions for each 
fare class on a given flight offered by the associated airline 2120, and the seat allocation 
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database 3400 maintains available inventory information for each fare class on a given 
flight offered by the associated airline 2120. The forecast and demand analysis database 
3500 contains information on each selling price for each fare class for a given flight, 
and the forecasted demand at each selling price as established by the RMS 2500. In 
5 addition, the data storage device 2530 preferably includes a CPO rules generation 
process 3900, discussed below in conjunction with Figure 39, to generate CPO rules by 
evaluating current inventory, pricing and revenue information, as well as historical 
patterns, to forecast future travel. 

The communications port 2540 connects each RMS 2500 to the CRS 

10 2400 and the CPO management system 2100. 

Figure 25b illustrates the manner in which the RMS 2500 utilizes a 
number of databases and other tools in implementing a conventional pricing and 
allocation process and the CPO rules generation process 3900. The particular format 
and content of the illustrative databases shown in Figure 25b are discussed in detail 

15 below in conjunction with Figures 33 through 35. It is noted that the conventional 
pricing and allocation process and the CPO rules generation process 3900 may be 
executed by the RMS 2500 initially when a flight is first added to the flight schedule, 
and then periodically to reallocate and price available inventory in response to demand 
and external events. 

20 Thus, when a flight is first added to the flight schedule of an airline 2 1 20, 

a record of the flight is preferably created by the airline reservation system 2150 in the 
flight schedule database 2800 with the appropriate itinerary information. In addition, 
the RMS 2500 will perform a conventional pricing and allocation process in conjunction 
with the CPO rules generation process 3900, shown in Figure 39, to initially populate 

25 the respective fields of the pricing and restrictions database 3300, seat allocation 
database 3400, and forecast and demand analysis database 3500 for the flight, as shown 
in Figure 25b. 

Generally, during the initial pricing and allocation process for a given 
flight, the RMS 2500 attempts to maximize revenue by establishing a plurality of fare 
30 classes and allocating the number of seats and price assigned to each fare class. The 
initial seat allocation and pricing information is stored in the seat allocation database 
3400 and the pricing and restrictions database 3300, respectively. The initial price for 
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each fare class and the forecasted demand is preferably stored in the forecast and 
demand analysis database 3500. In one embodiment, a separate fare class can be 
established by the RMS 2500 for selling tickets to CPO customers. Since tickets to 
CPO customers are generally sold at a discount, the RMS 2500 preferably only initially 
5 allocates seats to the CPO fare class which arc forecasted to be empty or unlikely to be 
sold when the flight actually departs. As is well known, an airline can utilize a 
conventional RMS 2500 to predict, based on available historical data, whether or not 
there will be empty seats on a given flight. 

As shown in Figure 25b, the airline reservation system (ARS) 2150 will 

10 access the established pricing and restrictions database 3300 and scat allocation 
database 3400 to perform itinerary queries. In addition, as tickets are sold by the airline 
2120, the ARS 2150 will preferably decrement the available inventory in the seat 
allocation database 3400. In this manner, the scat allocation database 3400 maintains an 
up-to-date representation of the available inventory on each flight. 

15 The RMS 2500 will continue to monitor the actual demand 2560 within 

each fare class relative to forecasted demand 2570, as illustrated by Figure 25c, 
dynamically reevaluating the inventory allocation and pricing of each fare class for a 
given flight in order to minimize the unanticipated excess inventory delta 2580. The 
RMS 2500 monitors current actual demand information by retrieving detailed inventory 

20 data from the seat allocation database 3400 or summary information from the forecast 
and demand analysis database 3500. In addition, the RMS 2500 will utilize the 
historical demand information stored in the forecast and demand analysis database 3500 
for prior periods, which essentially provides a demand curve for each selling price of a 
given fare class on each flight. For example, when allocating and pricing inventory for 

25 a given flight, the RMS 2500 may analyze demand trends for similar flights from 
previous relevant time periods, in a known manner. It is also noted that conventional 
RMSs typically respond to competitive forces and other external events, such as price 
wars or increased demand due to a large event, such as the Olympics, as shown in 
Figure 25 b. 

30 According to a feature of the present invention, an airline 2120 can 

correct for forecasting errors, if necessary, or other competitive forces which have 
produced unanticipated excess capacity 2580, by releasing tickets for sale to CPO 
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customers. Due to the confidential nature of the CPO rules, and the discouraged use of 
CPO tickets by full-fare business travelers, the airlines 2120, 2130 can sell such excess 
capacity at a discount, without undermining its existing published fare structure. Thus, 
in a preferred embodiment, the RMS 2500 will periodically execute the CPO rule 
5 generation process 3900, discussed below in conjunction with Figure 39, to generate 
CPO rules that encourage the sale of tickets to CPO customers. 

DATABASES 

Figure 26 illustrates an exemplary customer database 2600 that 
preferably stores information on each customer of the CPO management system 2100, 

10 including biographical information and billing information, such as a credit card 
number. The customer database 2600 maintains a plurality of records, such as records 
2605-2615, each associated with a different customer. For each customer name listed in 
field 2640, the customer database 2600 includes the customer's address in field 2645 
and credit card number in field 2655. In addition, the customer account database 2600 

15 preferably includes an identification (ID) number in field 2660. The ID number stored 
in field 2660 may be utilized, for example, to index a historical database (not shown) of 
previous ticket purchases and CPOs associated with the customer. 

Figure 27 illustrates an exemplary airline database 2700 which 
preferably stores information on each airline which is registered with the CPO 

20 management system 2100 to sell airline tickets to CPO customers, including address 
and contact information. The airline database 2700 maintains a plurality of records, 
such as records 2705-2715, each associated with a different airline. For each airline 
name listed in field 2740, the airline database 2700 includes address and contact 
information in fields 2745 and 2750, respectively. The contact information may 

25 comprise, for example, the name of an individual employee of the airline 2120 and a 
corresponding telephone number, web page URL, bulletin board address, pager number, 
telephone number, electronic mail address, voice mail address or facsimile number. 

In addition, in an embodiment where the CPO rules of a given airline are 
stored in an encrypted format, the cryptographic key of the associated airline is 

30 preferably stored in field 2755 of the airline database 2700. Finally, the airline database 
2700 preferably stores an indication in field 2760 of the percentage of CPOs which have 
been offered to each airline which have actually been accepted by the respective airline. 
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In this manner, the CPO management system 2100 can offer a particular CPO to airlines 
in a sequence that is ranked in accordance with the CPO acceptance rate, as discussed 
further below in conjunction with Figure 36b. In alternate embodiments, the airline 
database 2700 can incorporate fields to facilitate the processing of CPOs in accordance 
with sequences based on (i) the amount of inventory made available by each airline for 
sale to CPO customers, (ii) priorities negotiated by each airline, such as an airline 
priority over certain routes, or (iii) the highest commission rates paid by the airlines to 
the CPO management system 2100. 

Figure 28 illustrates an exemplary flight schedule database 2800 that 
preferably stores specific flight information for each O & D Pair, as well as connection 
information. The flight schedule database 2800 maintains a plurality of records, such as 
records 2805-2815, each associated with a different flight. For each O & D Pair listed 
in fields 2840 and 2845, the flight schedule database 2800 includes the date of each 
flight in field 2850, as well as the times of departure and arrival of the respective flight 
in fields 2855 and 2860. The airline and flight number associated with each flight are 
preferably indicated in fields 2865 and 2870, respectively, and any required connections 
are indicated in field 2875. 

Figures 29a and 29b illustrate an exemplary CPO database 2900 which 
preferably contains a record of each CPO being processed by the CPO management 
system 2100, including the terms of the CPO and the associated status. The CPO 
database 2900 maintains a plurality of records, such as records 2905 and 2910, each 
associated with a different CPO being processed by the system 2100. For each CPO 
identified by CPO number in field 2920, the CPO database 2900 includes the date the 
CPO was received in field 2925, and an identification (ID) number for the travel agent, 
if any, associated with the CPO in field 2930. It is noted that the travel agent ID 
number stored in field 2930 may be utilized, for example, to index a historical database 
(not shown) of previous ticket purchases and CPOs associated with the travel agent. 

In addition, the CPO database 2900 identifies the customer by name in 
field 2935, and by identification number in field 2940 and identifies any companion 
passengers in field 2945. The ID number stored in field 2945 is preferably utilized to 
cross-reference the corresponding information stored for the customer in the customer 
database 2600. 
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The parameters of the customer's itinerary and other pertinent restrictions 
are stored in fields 2950 through 2995 of the CPO database 2900. Specifically, the 
origin and destination cities are identified in fields 2950 and 2955, respectively, and any 
connection restrictions specified by the customer 21 10 are recorded in field 2960. The 
5 dates of the customer's departure and return are stored in fields 2965 and 2970, 
respectively. In an alternate embodiment (not shown), the CPO database 2900 could 
also permit the customer 21 10 to specify particular time-of-day (range) restrictions for 
the departure and return flights. 

The CPO database 2900 preferably stores an indication of the total 

10 number of passengers traveling together in field 2975, and sets forth the price the 
customer is willing to pay per ticket in field 2980. Any other miscellaneous restrictions 
specified by the customer will be recorded in field 2985, such as preferred airline(s), 
flights, or seat assignments. Field 2990 records the current status of the respective 
CPO, such as pending, accepted, rejected or expired. Finally, if the CPO ultimately 

15 results in a ticket being booked for the customer, the passenger name record number 
(PNR) associated with the ticket is stored in field 2995. Generally, a PNR is a record 
stored by the CRS 2400 containing information for each ticketed passenger, including: 
record number, passenger name(s), address for ticketing, billing information, such as 
credit card number, carrier(s) and flight number(s) for all segments, seat assignments, 

20 inventory class, aircraft type, airline-issued authorization code for discounted fare, 
selling price, and additional comments. 

As discussed further below, rather than reject a CPO, one or more 
airlines may issue a binding counteroffer to the CPO, which the customer 2110 may 
accept or reject. If a counteroffer is issued to a customer 2110, then a record of the 

25 counteroffer with any associated restrictions, is preferably created in the CPO database 
2900. For example, if an airline 2120 issues a counteroffer to the CPO number 23456 
stored in record 2905 of the CPO database 2900, then the status of the initial CPO is 
changed to "counter", and a further record (not shown) corresponding to the 
counteroffer may be stored in the CPO database 2900 under a modified CPO number 

30 indicating the counteroffer, such as CPO number 23456-COl . 

Figure 30a illustrates an exemplary secured airline rules database 3000 
which preferably maintains the CPO rules for one or more airlines associated with a 
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particular secured airline server 2300. As previously indicated, the secured airline rules 
database 3000 may be stored in an encrypted format to maintain the integrity and 
confidentiality of the highly sensitive information included in the CPO rules. The 
secured airline rules database 3000 maintains a plurality of records, such as records 
5 3002 and 3004, each associated with a different CPO rule. For each CPO rule identified 
by rule number in field 3010, the secured airline rules database 3000 includes the 
associated restrictions defined by the respective airline in fields 3012 through 3044. 

According to a feature of the invention, the CPO rules that are processed 
by the CPO management system 2300 may be of varying complexity. The particular 

10 restrictions set forth in the illustrative secured airl ine rules database 3000 are 
representative of the principles of the invention only. An airline can incorporate a 
subset of such restrictions and/or incorporate additional restrictions, as would be 
apparent to a person of ordinary skill. For example, the CPO rules of an airline 2120. 
may also incorporate restrictions on the minimum number of nights associated with the 

15 itinerary, or require the customer 21 10 to have a Saturday night stay. 

For illustrative purposes, the secured airline rules database 3000 shown 
in Figure 30a, allows an airline to create CPO rules by specifying some or all of the 
following restrictions in fields 3012 through 3044: origin and destination cities, 
connection restrictions, flight numbers included or excluded, dates and times of 

20 departure, departure days of the week, dates and times of return, return days of the 
week, number of passengers traveling, length of haul, average yield per seat, minimum 
price per ticket, inventory restrictions or seat availability, and advance purchase 
requirements. 

For example, record 3002, shown in Figure 30a, is associated with a 
25 CPO rule for a given airline which specifies that the airline will accept any CPO for 
travel from Newark, New Jersey (EWR) to Orlando, Florida (MCO) during the month 
of October, 1997, provided that (i) the customer travels on any flight departing on a 
Tuesday through Thursday, (ii) the tickets are booked within 21 days of departure, (iii) 
the price is at least $165 per ticket, (iv) K inventory is available on all flight segments of 
30 the customer's itinerary and (v) at least two (2) passengers are travelling together. 

Similarly, record 3004, shown in Figure 30a, is associated with a CPO 
rule for a given airline which specifies that the airline will accept any CPO having a 
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price of at least $150, for two or more people traveling together between New York, NY 
(JFK) and Chicago, IL (ORD) during April or May, 1997 where Q or K inventory is 
available on any flight between 1 1 a.m. and 2 p.m., where the flight departs on a 
Tuesday and returns on a Monday through Thursday, and is booked between 7 and 21 
days prior to travel and can be routed through the airline's Cleveland, OH or Pittsburgh, 
PA hubs. 

In an alternate or supplemental embodiment, the secured airline rules 
database 3000 can be implemented using a pair of inventory and pricing databases 3050, 
3075, illustrated in Figures 30b and 30c, respectively. In this embodiment, the CPO 
rules stored in the inventory database 3050 contain actual inventory on each flight that 
the airline has released for sale to CPO customers. The inventory database 3050 
maintains a plurality of records, such as records 3052-3056, each associated with a 
different CPO rule and flight. For each CPO rule identified by rule number in field 
3060, the inventory database 3050 includes an indication of the airline, flight number 
and dates in fields 3062 through 3066, respectively. In addition, the number of seats 
that may be sold by the CPO management system 2100 on each flight is indicated in 
field 3068. In a preferred embodiment, as inventory is sold by the CPO management 
system 2100, the available inventory recorded in the inventory database 3050 will be 
decremented. 

The pricing database 3075, shown in Figure 30c, maintains a plurality of 
records, such as records 3080-3084, each associated with a different O & D Pair. For 
each O & D Pair identified in fields 3090 and 3092, respectively, the pricing database 
3075 includes an indication of the airline, dates and minimum price in fields 3088, 3093 
and 3096, respectively. 

Thus, in such an alternate or supplemental embodiment, prior to 
accessing the inventory database 3050, the CPO management system 2100 will 
preferably query the CRS 2400 to identify possible flights which satisfy the customer's 
itinerary restrictions. Thereafter, the CPO management system 2100 will access the 
inventory database 3050 to determine if the airline has released any inventory on such 
identified flights to the CPO management system 2100 for sale to CPO customers. In 
one embodiment, the list of identified flights from the CRS 2400 can be sequenced to 
optimize customer preferences, and the inventory database 3050 can be searched in the 
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order of the sequenced list of flights, until available inventory is identified. Finally, if 
any available inventory satisfying the customer's itinerary is identified, then the CPO 
management system 2100 will access the pricing database 3075 shown in Figure 30c, to 
determine if the price specified by the customer exceeds the minimum price defined by 
5 the airline, as set forth in field 3096 of the pricing database 3075. 

Figure 31 illustrates an exemplary counteroffer rules database 3100 
which preferably stores a set of tolerances which may be utilized by the CPO 
management system 2100 to generate a counteroffer to a CPO if the CPO is within 
predefined tolerances of one or more restrictions associated with a given CPO rule. 

10 The counteroffer rules database 3100 maintains a plurality of records, such as records 
3105 and 3110', each associated with a different CPO rule. For each CPO rule identified 
by rule number in field 3120, the counteroffer rules database 3100 includes acceptable 
tolerances on the dates and times of departure and return in fields 3125 through 3140. 
In addition, the counteroffer rules database 3100 includes tolerances on the number of 

15 passengers traveling, length of haul and yield in fields 3145 through 3155, respectively. 
Finally, the counteroffer rules database 3100 records any permissible tolerances on the 
minimum price and advance purchase requirements in fields 3160 and 3165, 
respectively. 

As shown in Figure 31, the counteroffer rules database 3100 includes 
20 counteroffer rule number 45687 in record 3105, corresponding to CPO rule number 
45687 from Figure 30a. As illustrated in Figure 31, the CPO management system 2100 
is authorized to generate a counteroffer on behalf of an airline 2120 associated with 
CPO rule number 45687, if a given CPO fails to meet one or more of the restrictions of 
CPO rule number 45687, but the restrictions which are not met are within the 
25 predefined tolerances set forth in the counteroffer rules database 3100. For example, if 
a given CPO includes a customer-defined price of $140.00, but all other airline-defined 
restrictions of CPO rule number 45687 are met, a counteroffer should be generated 
containing a price of $150.00 since the price variation is within ten percent (10%) of the 
minimum price associated with CPO rule number 45687, as authorized by counteroffer 
30 rule number 45687. 

Figure 32 illustrates an exemplary secured airline audit database 3200 
which preferably maintains an audit trail for each CPO which is processed by the CPO 
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management system 2100. The secured airline audit database 3200 maintains a 
plurality of records, such as records 3205-3215, each associated with a different CPO 
that has been processed by the CPO management system 2100. For each CPO 
identified by CPO number in field 3220, the secured airline audit database 3200 
includes the response of the respective airline to the CPO in field 3225, and the date and 
time of the CPO in fields 3230 and 3235, respectively. In addition, if a ticket is booked 
for the customer 2110 on any airline, then the secured airline audit database 3200 
preferably stores the passenger name record (PNR) number associated with the ticket in 
field 3240 and an indication of whether or not the ticket was booked on the respective 
airline in field 3245. In a preferred embodiment, the entry in field 3245 indicates 
whether the ticket was booked (a) on the respective airline associated with the database, 
(b) with another airline or (c) if no ticket was issued at all. In this manner, the CPO 
management system 2100 can establish that a ticket was actually booked for each CPO 
which was accepted by at least one airline. 

Figure 33 illustrates an exemplary pricing and restrictions database 3300 
which maintains pricing information and related restrictions for each flight offered by 
the airlines 2120, 2130, as established and updated by the RMS 2500. The pricing and 
restrictions database 3300 includes a plurality of records, such as records 3305-3315, 
each associated with a different flight. For each flight identified by flight number in 
field 3325, the pricing and restrictions database 3300 includes the date of the flight in 
field 3330 and the respective price and restrictions associated with each inventory class 
in fields 3335 through 3350. 

Figure 34 illustrates an exemplary seat allocation database 3400 which 
maintains available inventory information for each fare class on a given flight offered 
by the airlines 2120, 2130, as allocated and updated by the RMS 2500, In addition, as 
inventory is sold by an airline, the airline's ARS 2150 will preferably decrement the 
available inventory recorded in the seat allocation database 3400. The seat allocation 
database 3400 includes a plurality of records, such as records 3405-3420, each 
associated with a different flight. For each flight identified by flight number in field 
3425, the seat allocation database 3400 includes the departure date of the flight in field 
3430 and the respective inventory available in each inventory class in fields 3435 
through 3440. In addition, the seat allocation database 3400 preferably includes an 
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indication of the total number of seats booked on the flight in field 3445 and total 
capacity available on the flight in field 3450. 

Figure 35 illustrates an exemplary forecast and demand analysis database 
3500, which records each selling price for each fare class for a given flight, and the 
5 forecasted demand at each selling price as established by the RMS 2500. As previously 
indicated, when a flight is first added to the flight schedule of an airline 2120, a record 
of the initial price for each fare class and the forecasted demand is preferably created in 
the forecast and demand analysis database 3500. In addition, new records are 
preferably created for each new selling price that is established for each fare class by the 

10 RMS 2500, as part of the dynamic inventory reallocation process. 

The forecast and demand analysis database 3500 includes a plurality of 
records, such as records 3505-3525, each associated with a different selling price for a 
given fare class on a given flight. For each flight number identified in field 3530, the 
forecast and demand analysis database 3500 includes the departure date, and origin and 

15 destination cities in fields 3535 through 3545, respectively, and the corresponding 
offered prices and fare classes in fields 3550 and 3555, respectively. Finally, the 
forecast and demand analysis database 3500 preferably records the actual quantity of 
tickets sold by the airline at each offered price for each fare class in field 3560 and the 
corresponding forecasted quantity in field 3565. The actual quantity of tickets sold may 

20 be recorded in field 3560 in real-time as tickets are actually sold or by means of batch 
processing on a periodic basis. 

PROCESSES 

As discussed above, the CPO management central server 2200 preferably 
executes a CPO management process 3600, shown in Figures 36a through 36c, to 

25 receive each CPO from a customer 2110 and to compare the CPO against the rules of 
each airline in order to determine whether to accept, reject or counter the CPO on behalf 
of an airline. As illustrated in Figure 36a, the CPO management process 3600 begins 
the processes embodying the principles of the present invention during step 3604, when 
a customer or travel agent accesses the CPO management system 2100. 

30 Thereafter, during step 3608, the CPO management central server 2200 

will receive the customer information, itinerary, price and other restrictions from the 
customer 2110 which are required to populate the customer database 2600, if required 
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for a new customer, and the CPO database 2900. A record of the CPO is preferably 
created in the CPO database 2900 with the received information during step 3612, and 
with the status field set to "pending." 

Appropriate legal language is preferably displayed or read to the 
5 customer 2110 during step 3616, and the CPO management system 2100 will wait for 
an acknowledgment from the customer 2110 to form a binding conditional purchase 
offer (CPO). The price is extracted from field 2980 of the CPO database 2900 and the 
appropriate customer information, including credit card number, is extracted from the 
customer database 2600 during step 3620. Thereafter, the merchant ID associated with 

10 the CPO management system 2100, together with an appropriate billing descriptor, the 
total purchase amount (preferably equal to the price specified by the customer 2110) 
and the credit card information, are transmitted to the credit card issuer durine step 3624 
for pre-authorization. 

A test is then preferably performed during step 3628 to determine if an 

15 authorization code has been received from the credit card issuer. If it is determined 
during step 3628 that the credit card issuer has not authorized the purchase amount, then 
another credit card is preferably requested from the customer 21 10 during step 3632 and 
program control returns to step 3624 to continue processing in the manner described 
above. 

20 tf> however, it is determined during step 3628 that the credit card issuer 

has authorized the purchase amount, then the CPO is accepted for processing during 
step 3636 and program control continues to step 3640 (Figure 36b). The CPO 
management process 3600 preferably executes the evaluation process 3700, discussed 
below in conjunction with Figure 37, for each airline during step 3640. The CPO record 

25 created during step 3612 is passed to the evaluation process 3700 for comparison 
against the CPO rules of one airline, such as the airline 2120, to generate a response for 
the airline to the given CPO. As previously indicated, the airline's response to a CPO 
may be to accept, reject or counter the CPO. As discussed further below, the evaluation 
process 3700 will return the airline's response to the CPO, as well as a flight number if 

30 the CPO is accepted or countered by the airline. 

In an alternate embodiment, the evaluation process 3700 can be 
performed for each airline in a predefined sequence until one airline accepts the CPO. 



76 



WO 98/10361 



PCTYUS97/15492 



For example, the evaluation process 3700 can be performed in sequence based upon (i) 
the amount of inventory made available by each airline for sale to CPO customers, (ii) 
the CPO acceptance rate of each airline, as recorded in the airline database 3700, (iii) 
priorities negotiated by each airline, such as an airline priority over certain routes, or 
(iv) the highest commission rates paid by the airlines to the CPO management system 
2100. In this manner, the sequence can be determined by factors that incent 
participation by the airlines, and/or by factors that optimize revenue to the CPO 
management system 2100. It is noted that in the preferred embodiment, the customer 
2110 will pay the price defined by the customer if the CPO is accepted by an airline, 
regardless of the minimum price the airline would be willing to accept or whatever 
sequencing criteria is utilized by the CPO management system 2100 to process the 
CPO. 

As shown in Figure 36b, a lest is preferably performed during step 3644 
to determine if the CPO was accepted by at least one airline. If it is determined during 
step 3644 that the CPO was accepted by at least one airline then a further test is 
preferably performed during step 3648 to determine if the CPO was accepted by more 
than one airline. If it is determined during step 3648 that the CPO was not accepted by 
more than one airline then program control proceeds directly to step 3672 (Figure 36c) 
to book the ticket. 

If, however, it is determined during step 3648 that the CPO was accepted 
by more than one airline, then a tie breaker algorithm is preferably executed during step 
3652 to determine which airline acceptance to utilize. For example, the tie breaker 
algorithm can select an airline offering an itinerary which maximizes the convenience to 
the customer 2110, maximizes the profit to the CPO management system 2100 or 
optimizes the inventory available for sale by the CPO management system 2100. It is 
noted that in the alternate embodiment, where the evaluation process 3700 is performed 
for each airlines in a predefined sequence until one airline accepts the CPO, a tie 
breaker algorithm will not be required. In a further alternate embodiment, the customer 
2110 may select for himself which airline acceptance to utilize. Thereafter, program 
control proceeds to step 3672 (Figure 36c) to book the ticket. 

In order to book the ticket, the information required to create a passenger 
name record (PNR) is extracted from the customer database 2600, the CPO database 
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2900 and the inventory and flight information received from the evaluation process 
3700 or CRS 2400. As previously indicated, a PNR generally includes the following 
parameters: record number, passenger name(s), address for ticketing, billing 
information, such as credit card number, flight number(s) for all segments, carrier(s), 

5 seat assignments, inventory class, aircraft type, airline-issued authorization code for 
discounted fare, selling price, and additional comments. 

Thereafter, during step 3674, the PNR is transmitted to the airline 
reservation system 2150 of the airline upon which the ticket will be booked or the CRS 
2400 to establish a reservation. The CPO management process 3600 will then transmit 

10 the merchant ID associated with the CPO management system 2100, together with an 
appropriate billing descriptor, the total purchase amount (preferably equal to the price 
specified by the customer 21 10) and the credit card information, to the credit card issuer 
during step 3678 for payment. 

The record of the CPO in the CPO database 2900 is updated during step 

15 3682 with the assigned PNR number and the status field is changed to "accepted." 
Finally, an audit process 3800, discussed below in conjunction with Figure 38, is 
executed by the CPO' management process 3600 during step 3686 for each airline to 
maintain an audit trail for each CPO which is processed by the CPO management 
system 2100. As previously indicated, the audit process 3800 will create an entry in the 

20 secured airline audit database 3200 which can be utilized to establish that a ticket was 
actually booked by the CPO management system 2100 for each CPO which was 
accepted by at least one airline. 

If, however, it was determined during step 3644 (Figure 36b) that the 
CPO was not accepted by at least one airline, then a further test is performed during step 

25 3 6 5 6 to determine if at least one airline provided a counteroffer to the CPO. If it is 
determined during step 3656 that at least one airline did provide a counteroffer to the 
CPO, then the status of the initial CPO is changed to "counter", and a record of the 
counteroffer is preferably created in the CPO database 2900 during step 3660, for 
example using the original CPO number with a "-CO" extension. Thereafter, the 

30 counteroffer(s) are transmitted to the customer 2110 during step 3664. In an alternate 
embodiment, if the CPO is within predefined tolerances, rather than receiving one or 
more counteroffers, the customer 21 10 can be instructed to resubmit the CPO at a later 
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time, or the CPO management system 2100 can periodically reexecute the CPO until the 
CPO is accepted or until the CPO expires. It is noted that in view of the dynamic nature 
of the CPO rules, a CPO that is initially rejected may be subsequently accepted by one 
or more airlines. 

A test is then preferably performed during step 3668 to determine if the 
customer 21 10 accepted one of the counteroffer(s). If it is determined during step 3668 
that the customer 21 10 did accept a counteroffer, then program control proceeds to step 
3672 (Figure 36c) to book the ticket, in the manner described above. If, however, it is 
determined during step 3668 that the customer 2110 did not accept a counteroffer, then 
program control proceeds to step 3696 (Figure 36c), where the CPO management 
process 3600 will transmit the customer's rejection of the counteroffer to the airline(s) 
making the counteroffer. Thereafter, during step 3698, the CPO management process 
3600 will update the status of the counteroffer associated with the CPO in the CPO 
database 2900 to "rejected." Program control proceeds to step 3686 in the manner 
described above and then terminates during step 3699. 

If, however, it was determined during step 3656 (Figure 36b) that no 
airlines provided a counteroffer to the CPO, then program control proceeds to step 3690 
(Figure 36c), where the CPO management process 3600 will transmit the rejection of 
the CPO to the customer 2110. Thereafter, the status of the CPO in the CPO database 
2900 is updated to "rejected" during step 3694. Program control proceeds to step 3686 
in the manner described above and then terminates during step 3699. 

As discussed above, the CPO management process 3600 executes an 
evaluation process 3700, during step 3640. An exemplary evaluation process 3700 is 
shown in Figures 37a and 37b. In one embodiment, the evaluation process 3700 is 
preferably customized for each airline, so that each evaluation process 3700 receives the 
CPO record from the CPO management process 3600 in a standard format for 
comparison against the rules of the associated airline, such as the airline 2120, and 
returns a standard response of the airline to the CPO. such as accept, reject or counter. 
In addition, if the response of the airline is to accept or counter the CPO, the evaluation 
process 3700 preferably also returns the selected flight number. 

As shown in Figure 37a, the evaluation process 3700 initially extracts the 
O & D Pair from the CPO record during step 3705 and thereafter identifies all CPO 
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rules in the secured airline rules database 3000 which are pertinent to the extracted O & 
D Pair during step 3710. The customer defined restrictions from fields 2960 through 
2995 of the CPO record are then compared to the corresponding airline defined 
restrictions from fields 3016 through 3044 of the secured airline rules database 3000 

5 during step 37 1 5, for each CPO rule identified during the previous step. 

Thereafter, a test is performed during step 3720 to determine if the CPO 
satisfies at least one airline rule. For example, CPO number 23452, stored in record 
2910 of the CPO database 2900 (Figures 29a and 29b), defines an O & D Pair of New 
York (JFK) to Chicago (ORD). Thus, the evaluation process 3700 will access the 

10 secured airline rules database 3000 and identify all CPO rules for this O & D Pair. In 
the illustrative secured airline rules database 3000 shown in Figure 30a, CPO rule 
number 23452 is identified as the only rule pertinent to this O & D Pair. Thereafter, 
each of the customer defined restrictions from fields 2960 through 2995 of the CPO 
number 23452 are compared to the corresponding airline defined restrictions from fields 

15 3016 through 3044 of CPO rule number 23452. Since the customer is willing to make 
one stop (field 2960), the airline requirement of routing through Cleveland or Pittsburgh 
(field 3016) can be satisfied. In addition, the customer's dates of departure and return 
requirements (fields 2965 and 2970) satisfy the airline's dates, times and day of week 
requirements for both the departure and return legs of the trip (fields 3020 through 

20 3 0 32). In addition, the number of passengers traveling satisfies the airline requirement 
set forth in field 3034 and the customers price (field 2980) exceeds the airline's defined 
minimum price (field 3040). Thus, CPO number 23452 will be accepted by the airline 
associated with CPO rule number 45687, provided that Q or K inventory is available 
(field 3042) and the CPO is being processed between 7 and 21 days prior to flight (field 

25 3044). 

In one embodiment, the CPO management system 2100 allows the 
airlines 2120, 2130 to specify CPO rules in a format that accepts a given CPO, 
conditioned upon the CPO management system 2100 finding inventory available that 
meets the requirements of the airline, as set forth in the CPO rule, and the requirements 
30 of the customer 2110, as set forth in the CPO itself. For example, CPO rule number 
23452, shown in Figure 30a, is conditioned upon Q or K inventory being available. 
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Thus, if it is determined during step 3720 that the CPO satisfies at least 
one airline rule, then a further test is preferably performed during step 3725 to 
determine if any of the satisfied rules are conditioned on inventory being available. 

If it is determined during step 3725 that none of the satisfied rules arc 
conditioned on inventory being available, then program control proceeds directly to step 
3735, discussed below. If, however, it is determined during step 3725 that one or more 
satisfied rules are conditioned on inventory being available, then the CRS or ARS is 
accessed during step 3730 to identify flights, if any, with seats available and meeting the 
appropriate restrictions of both the satisfied CPO rule and the CPO. 

Thereafter, a test is performed during step 3735 to determine if more 
than one flight satisfying the CPO has been identified. If it is determined during step 
3735 that only one satisfactory flight has been identified, then program control proceeds 
directly to step 3745 (Figure 37b), discussed below. 

If, however, it is determined during step 3735 that more than one 
satisfactory flight has been identified, then one flight is selected during step 3740 
(Figure 37b) which most closely matches the customer preferences set forth in the CPO 
or maximizes the convenience for the customer. Alternatively, each airline 2120 can 
define its own criteria for the CPO management system 2100 to utilize to select a single 
flight. Thereafter, the response will be set to "accept 11 during step 3745, and program 
control will return to the CPO management process 3600 during step 3770 with the 
defined response and selected flight number. 

If, however, it was determined during step 3720 (Figure 37a) that the 
CPO does not satisfy at least one airline rule, then program control proceeds to step 
3750 (Figure 37b), where a further test is performed to determine if the CPO is within 
tolerances specified by the airline for generating a counteroffer. As previously 
indicated, the counteroffer rules database 3100 is preferably stored by each secured 
airline server 2300 to maintain a set of tolerances which may be utilized by the CPO 
management system 2100 to generate a counteroffer to a CPO on behalf of an airline, if 
the CPO is within predefined tolerances of one or more restrictions associated with a 
given CPO rule. 

Thus, if it is determined during step 3750 that the CPO is within 
tolerances specified by the airline for generating a counteroffer, then a counteroffer is 
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generated during step 3760 with the appropriate modified terms, as retrieved from the 
counteroffer rules database 3100. Thereafter, the response will be set to 'counter" 
during step 3765, and program control will return to the CPO management process 3600 
during step 3770 with the defined response and selected flight number. 

5 If, however, it is determined during step 3750 that the CPO is not within 

tolerances specified by the airline for generating a counteroffer, then the response will 
be set to "rejected" during step 3755, and program control will return to the CPO 
management process 3600 during step 3770 with the defined response and the selected 
flight number equal to null. 

10 As previously indicated, the CPO management process 3600 preferably 

executes an audit process 3800 during step 3686 for each airline to maintain an audit 
trail for each CPO that is processed by the CPO management system 2100. An 
exemplary audit process 3800 is shown in Figure 38. The audit process 3800 will 
preferably create an entry in the secured airline audit database 3200 which can be 

15 utilized by the CPO management system 2100 to establish that a ticket was actually 
booked by the CPO management system 2100 for each CPO which was accepted by at 
least one airline. In this manner, the airlines 2120 can be assured that the risk of a 
customer 2110, another airline 2130 or a third party utilizing the CPO management 
system 2100 to obtain the underlying price flexibility of the airline 2120 is minimized. 

20 As shown in Figure 38, the audit process 3800 will initially decrement 

the inventory in the secured airline rules database, if necessary, during step 3810. For 
example, inventory should be decremented only if the ticket was ultimately booked by 
the associated airline, and the CPO rule which was utilized to accept the CPO actually 
included inventory released by the airline for sale to CPO customers, as opposed to a 

25 CPO rule which was conditioned upon inventory being available. 

Thereafter, the audit process 3800 preferably creates a record of the CPO 
in the secured airline audit database 3200, during step 3815, including the CPO number, 
the PNR associated with the ticket issued by the CPO management system 2100, if any, 
to the customer 21 10, and an indication of whether the ticket, if any, was booked on the 

30 corresponding airline. Program control will then return to the CPO management 
process 3600 during step 3820. 
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An illustrative CPO rules generation process 3900, shown in Figure 39, 
is preferably executed by the RMS 2500 initially when a flight is first added to the flight 
schedule, and then periodically to reallocate and price available inventory in response to 
demand and external events. Thus, a test is initially performed during step 3905 to 
5 determine if the current inventory allocation by the RMS 2500 is the initial allocation 
for the flight being allocated. If it is determined during step 3905 that the current 
inventory allocation is the initial allocation for the flight being allocated, then a further 
test is performed during step 3910 to determine if the flight is predicted, using 
conventional methods, to likely depart with empty seats. 

10 If it is determined during step 3910 that the flight is not likely to depart 

with empty seats, then program control will terminate during step 3985. If, however, it 
is determined during step 3910 that the flight is likely to depart with empty seats, then 
the CPO rule generation process 3900 will preferably allocate the empty seats to a 
special fare class for CPO customers during step 3915. Thereafter, an appropriate 

15 minimum fare and other restrictions for such tickets will be established during step 
3920. 

The pricing and restrictions database 3300, seat allocation database 3400, 
and forecast and demand analysis database 3500 for the flight will be updated during 
step 3925 with the newly established fare class, the allocated inventory and the initial 
20 price. Thereafter, the CPO rules generation process 3900 will preferably generate a 
CPO rule containing the allocated inventory, established minimum price and other 
restrictions during step 3930 and then transmit the generated CPO rule to the associated 
secured airline server 2300 during step 3935. Program control will then terminate 
during step 3985. 

25 If, however, it was determined during step 3905 that the current 

inventory allocation is not the initial allocation for the flight being allocated, then 
program control proceeds to step 3950 to reallocate a previous allocation for one or 
more fare classes of a given flight in order to minimize the unanticipated excess 
inventory delta 2580. Thus, a test is performed during step 3950 to determine if the 

30 forecasted demand exceeds the actual demand by more than a predefined tolerance for 
any fare class. In one embodiment, the RMS can make this determination utilizing the 
summary information recorded in fields 3560 and 3565 of the forecast and demand 
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analysis database 3500. In addition, the RMS 2500 can generate the predefined 
tolerance utilized in step 3950 by analyzing historical demand information stored in the 
forecast and demand analysis database 3500 for prior periods. 

If it is determined during step 3950 that the forecasted demand does not 
exceed the actual demand by more than a predefined tolerance for any fare class, then 
there is no need to reallocate the existing allocation and program control will terminate 
during step 3985. It is noted that if actual demand exceeds forecasted demand, the RMS 
2500 can remove inventory that was previously allocated for sale to CPO customers. 

If, however, it is determined during step 3950 that the forecasted demand 
does exceed the actual demand by more than a predefined tolerance for any fare class, 
then the RMS 2500 will preferably allocate the excess capacity, or a portion thereof, for 
sale to CPO customers during step 3955. Thereafter, an appropriate minimum fare and 
other restrictions for such tickets will be established during step 3960. 

The pricing and restrictions database 3300, seat allocation database 3400, 
and forecast and demand analysis database 3500 for the flight will be updated during 
step 3965 with the reallocated inventory and the established price. Thereafter, the CPO 
rules generation process 3900 will generate a CPO rule containing the allocated 
inventory, established minimum price and other restrictions during step 3970 and then 
transmit the generated CPO rule to the associated secured airline server 2300 during 
step 3980. Program control will then terminate during step 3985. 

CRUISE IMPLEMENTATION 

Although the CPO management system 2100 has been primarily 
illustrated herein as a system for selling airline tickets, the CPO management system 
2100 could be utilized to sell cruise tickets as well, as would be apparent to a person of 
ordinary skill. In such an embodiment, each secured airline server 2300 would be 
associated with one or more cruise operators, as opposed to airlines, and each secured 
server 2300 stores, among other things, the CPO rules defined by any associated cruise 
operators, in a similar manner to the secured server 2300 described above in an airline 
implementation. 

In addition, the revenue management system 2500 and the airline 
reservation system 2150 would be embodied as the revenue management system and 
reservation system, respectively, of each cruise operator. The cruise revenue 
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management system establishes pricing and inventory information and generates CPO 
rules in a similar manner to the revenue management system described above in an 
airline implementation. Similarly, the cruise reservation system performs itinerary 
queries and makes reservations with the respective cruise operator in a similar manner 
to the reservation system described above in an airline implementation. 

Thus, the CPO management system 2100 receives CPOs from potential 
cruise travelers and evaluates the CPOs against a set of CPO rules provided by each of a 
plurality of cruise operators. An illustrative CPO database 4000 for a cruise 
implementation is illustrated in Figures 40a and 40b. The CPO database 4000 
preferably stores a record of each CPO being processed by the CPO management 
system 2100, including the terms of the CPO and the associated status. The CPO 
database 4000 maintains a plurality of records, such as records- 4005 and 4010, each 
associated with a different CPO being processed by the system 2100. For each CPO 
identified by CPO number in field 4020, the CPO database 4000 includes the date the 
CPO was received in field 4025, and an identification (ID) number for the travel agent, 
if any, associated with the CPO in field 4030. It is noted that the travel agent ID 
number stored in field 4030 may be utilized, for example, to index a historical database 
(not shown) of previous ticket purchases and CPOs associated with the travel agent. 

In addition, the CPO database 4000 identifies the customer by name in 
field 4035, and by identification number in field 4040. Any companion passengers are 
identified in field 4045. The ID number stored in field 4040 is preferably utilized to 
cross-reference the corresponding information stored for the customer in the customer 
database 2600. 

The parameters of the customer's itinerary and other pertinent restrictions 
are stored in fields 4050 through 4085 of the CPO database 4000. Specifically, the 
origin and destination ports are identified in fields 4050 and 4055, respectively, and any 
port restrictions specified by the customer 2110 are recorded in field 4060. The 
departure and return dates are stored in fields 4065 and 4070, respectively. 

The CPO database 4000 preferably stores an indication of the total 
number of passengers traveling together in field 4075, and sets forth the price the 
customer is willing to pay per ticket in field 4080. Any other miscellaneous restrictions 
specified by the customer will be recorded in field 4085, such as preferred cruise 
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operator(s), berths, cabin assignments or meal times. Field 4090 records the current 
status of the respective CPO, such as pending, accepted, rejected or expired. 

An illustrative secured rules database 4100 for a cruise implementation is 
shown in Figure 41 for maintaining the CPO rules for one or more cruise operators 
5 associated with the respective secured server 2300. The secured rules database 4100 
may be stored in an encrypted format to maintain the integrity and confidentiality of the 
highly sensitive information included in the CPO rules. The secured rules database 
4100 maintains a plurality of records, such as records 4102 and 4104, each associated 
with a different CPO rule. For each CPO rule identified by rule number in field 4110, 

10 the secured rules database 4100 includes the associated restrictions defined by the 
respective cruise operator in fields 4112 through 4144. 

According to a feature of the invention, the CPO rules that are processed 
by the CPO management system 2100 may be of varying complexity. The particular 
restrictions set forth in the illustrative secured rules database 4100 are representative of 

15 the principles of the invention only. A cruise operator, airline or other seller can 
incorporate a subset of such restrictions and/or incorporate additional restrictions, as 
would be apparent to a person, of ordinary skill. 

For illustrative purposes, the secured rules database 4100 shown in 
Figure 41, allows a cruise operator to create CPO rules by specifying some or all of the 

20 following restrictions in fields 4112 through 4144: origin ports, cruise numbers 
(included or excluded), dates and times of departure, departure day of the week, dates 
and times of return, return day of the week, number of passengers traveling, length of 
haul, average yield per cabin, minimum price per ticket, inventory restrictions or cabin 
availability, and advance purchase requirements. 

25 For example, record 4102, shown in Figure 41, is associated with a CPO 

rule for a given cruise operator which specifies that the cruise operator will accept any 
CPO for travel from St. Thomas during the month of October, 1997, provided that (i) 
the customer travels on any cruise departing and returning on a Tuesday through 
Thursday, (ii) the tickets are booked within two (2) months of departure, (iii) the yield is 

30 at least $1.20 per mile per cabin and the price is at least $529 per person, (iv) is not for 
luxury class travel and (v) at least two (2) passengers are travelling together. 
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POST-SELL FOR MULTIPLE BENDS 
As discussed above, if a CPO is accepted by more than one airline or 
cruise operator, then a tie breaker algorithm is preferably executed by the CPO 
management process 3600 during step 3652 to determine which airline acceptance to 
utilize. For example, the tie breaker algorithm can select a seller offering an itinerary 
which maximizes the convenience to the customer 2110, maximizes the profit to the 
CPO management system 2100, optimizes the inventory available for sale by the CPO 
management system 2100 or permits the customer 2110 to select for himself which 
airline or cruise operator acceptance to utilize. In an alternate implementation, if a CPO 
is accepted by more than one cruise operator, the CPO management system 2100 
executes a post-sell multi-bind process 4200, shown in Figure 42, to permit each 
accepting seller to directly market to the customer 2110 and post-sell their product. 
Thus, the customer 2110 still selects for himself which cruise operator acceptance to 
utilize, based on materials or incentives furnished by each seller. The customer 21 10 is 
still bound by the CPO management system 2100, in accordance with the terms of the 
CPO. In other words, the customer 21 10 is obligated to purchase the goods or services 
specified by the CPO, but the buyer must decide which cruise operator to utilize, based 
on materials provided to the customer 2110 directly by each accepting cruise operator. 

For example, a customer 2110 may submit a CPO for a cruise during the 
month of March, 1998, anywhere in the Virgin Islands, in a grade A cabin with late 
dining, for $800.00. The CPO is provided to a plurality of cruise operators. Three 
cruise operators accept the CPO. The CPO management system 2100 then binds the 
customer 21 10 on the credit card account identified with the offer, in accordance with 
the restrictions of the CPO. The CPO management system 2100 then provides a 
channel of communication between the customer 2110 and the accepting sellers, or 
provides the customer contact information to each accepting cruise operator, who each 
attempt to market their product in an attractive manner. The customer 2110 then selects 
one of the three accepting sellers. Thus, each cruise operator knows that they have a 
one-in-three chance of selling a cruise, at the price specified by the CPO. It is 
anticipated that cruise operators would aggressively market to such guaranteed 
purchasers, particularly in view of the high marginal profits associated with each cruise 
traveler. 
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It is noted that the channel of communication provided by the CPO 
management system 2100 between the customer 2110 and each accepting seller may be 
an interactive web-site or other electronic mechanism that permits each accepting seller 
to present the customer 2110 with detailed information about the cruise they are 
5 attempting to market. For example, the interactive web-site might include virtual 
representations of different aspects of the cruise package, such as the actual cruise ship 
and cabins, as well as the various ports that the cruise will visit and the available 
activities. In this manner, the buyer can explore the virtual cruise representation using 
known technology. 

10 Figure 42 illustrates an illustrative post-sell multi-bind process 4200 

which may be implemented by the CPO management central server of Figure 22 to 
permit each accepting seller to directly market to the customer 21 10 in an attempt to 
post-sell their product. The post-sell multi-bind process 4200 is preferably executed by 
the CPO management process 3600 during step 3652, in lieu of the tie breaker 

15 algorithm, to determine which cruise operator acceptance to utilize. As illustrated in 
Figure 42, the post-sell multi-bind process 4200 begins during step 4210, by instructing 
the accepting cruise operators or other sellers to provide post-sell information for a 
designated customer 21 10. The CPO management system 2100 then preferably receives 
the post-sell information from the accepting operators during step 4220 and transmits, 

20 or otherwise makes available, the received information to the customer 21 10 during step 
4230. Finally, the post-sell multi-bind process 4200 receives the decision of the 
customer 2110 regarding which operator to utilize, before program control returns to the 
CPO management process 3600 during step 4250. 

In an alternate implementation, if a CPO is accepted by more than one 

25 cruise operator, then the CPO management system 2100 can bind each of the accepting 
sellers to the one CPO. The original buyer can be assigned one of the sellers in 
accordance with the tie breaker algorithm or the alternative post-sell multi-bind process 
4200 disclosed herein. In this manner, the CPO management system 2100 can then 
resell the excess inventory to other buyers at or above the price associated with the 

30 initially accepted CPO. 
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EXCLUDED SELLER CPO EVALUATION 
As previously indicated, a CPO submitted by a customer 2110 can 
specify one or more preferred airline(s), cruise operators or other sellers, as applicable. 
Thus, the CPO management system 2100 will provide the CPO to each specified seller 
to determine if one or more of the sellers are willing to accept the CPO. In a 
supplemental embodiment, the CPO management system 2100 preferably executes an 
excluded seller CPO evaluation process 4400, discussed below in conjunction with 
Figures 44a and 44b, to provide the CPO to the excluded sellers who may make 
counteroffers to the customer 21 10 before one of the specified sellers accepts the CPO. 
The excluded sellers may make counteroffers which are more favorable than the 
original terms of the CPO specified by the customer 2110, in an attempt to obtain the 
business. In this manner, the CPO management system 2100 can sell the rights to 
receive CPO information to excluded sellers or collect a larger percentage commission 
for any counteroffers which are accepted by a customer 2110. 

For example, in the cruise industry, first time cruisers tend to develop a 
specific brand loyalty. Thus, when considering future cruises, such customers 2110 
may submit a CPO to a very limited number of cruise operators. The CPO management 
system 2 100 would submit the CPO to the specified cruise operators, in accordance with 
the terms of the CPO, and also submit the CPO to one or more excluded cruise 
operators. The CPO management system 2100 preferably utilizes an excluded operator 
counteroffer database 4300, shown in Figure 43. to maintain any counteroffers received 
from the excluded operators, before the CPO is accepted by one of the customer- 
specified operators. 

An illustrative excluded operator counteroffer database 4300 for a cruise 
implementation is shown in Figure 43. The excluded operator counteroffer database 
4300 maintains a plurality of records, such as records 4305 through 4315, each 
associated with a different counteroffer received from an excluded operator. For each 
counteroffer identified by number in field 4325, the excluded operator counteroffer 
database 4300 includes the corresponding CPO number, a customer identifier, the 
excluded operator, the terms of the counteroffer and the associated status in fields 4330 
through 4350, respectively. For example, if a customer's CPO initially specified that 
the offer be submitted to Holland AmericaLine or Seaborn Cruise Lines, the CPO 
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management system 2100 might first submit the offer to Carnival, Princess and Royal 
Caribbean Cruise Lines. As shown in Figure 43, each of the excluded operators submit 
counteroffers of $600, $600 and $575, respectively. If none of the operators originally 
specified by the customer's CPO have not yet accepted, then the customer 2110 is 

5 provided the option of accepting one of the counteroffers. If the customer 2110 accepts 
a counteroffer, then the customer 21 10 is bound to the terms of the counteroffer, and the 
original CPO is cancelled. 

Figures 44a and 44b describe an illustrative excluded seller CPO 
evaluation process 4400. This process 4400 may be implemented by the CPO 

10 management central server of Figure 22 to provide the CPO information to the sellers 
excluded by the terms of the original offer. Those excluded sellers can then attempt to 
obtain the business, before one of the sellers specified by the terms of the CPO accepts 
the CPO. As discussed below, the excluded seller CPO evaluation process 4400 is 
preferably executed in conjunction with the CPO management process 3600. As 

15 illustrated in Figure 44a, the excluded seller CPO evaluation process 4400 begins during 
step 4405, upon receipt of a CPO from a customer 2110 and storage of the CPO in the 
CPO database 2900 or 4000. Thereafter, the CPO is evaluated during step 4410 to 
retrieve any operators specified by the customer 2110. The operator database is 
accessed during step 4415 to identify potential operators to which the CPO information 

20 can be provided. 

A test is then performed during step 4420 to determine if there arc one or 
more operators excluded from the terms of the CPO. If it is determined during step 
4420 that no operators are excluded from the customer's CPO, then the CPO 
management process 3600 continues operation as described above. If, however, it is 

25 determined during step 4420 that one or more operators are excluded from the 
customer's CPO, then the CPO information is preferably transmitted to each specified 
and excluded operator during step 4430. It is noted that the CPO can be provided to 
excluded operators before specified operators, or concurrently. 

Any counteroffers are then received from the excluded operators during 

30 step 4435, and stored in the excluded operator counteroffer database 4300 during step 
4440. Each of the received counteroffers are then presented to the customer 2110 
during step 4445. A test is then performed during step 4450 to determine if the customer 
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2110 accepts any of the counteroffers before the original CPO is accepted by any of the 
specified operators. If it is determined during step 4450 that the customer 21 10 does not 
accept any of the counteroffers before the original CPO is accepted by any of the 
specified operators, then the CPO management process 3600 continues operation as 
5 described above. 

If, however, it is determined during step 4450 that the customer 21 10 has 
accepted a counteroffer before the original CPO is accepted by any of the specified 
operators, then the original CPO is terminated or cancelled and the status of the original 
CPO in the CPO database 2900, 4000 is changed to "cancelled" during step 4460. 

10 Thereafter, the status of the accepted counteroffer is changed to "accepted" and the 
status of the rejected counteroffers, if any, are changed to "rejected" in the excluded 
operator counteroffer database 4300 during step 4465. Finally, program control returns 
to the CPO management process 3600 and continues in the manner described above. 

Although the post-sell multi-bind process 4200 and the excluded seller 

15 CPO evaluation process 4400 have been illustrated herein in a cruise embodiment, it is 
noted that the post-sell multi-bind process 4200 and the excluded seller CPO evaluation 
process 4400 are applicable in other industries as well, including the airline and other 
travel-related industries, the long distance telephone industry and the finance industry, 
as would be apparent to a person of ordinary skill. 

20 PACKAGE CPO MANAGEMENT S YSTEM 

A further embodiment of the present invention, suitable for processing 
the sale of packages of goods and services, is discussed below in conjunction with 
Figures 45 through 57. Figure 45 shows a conditional purchase offer (CPO) 
management system for receiving and processing CPOs from one or more buyers, 

25 utilizing buyer interfaces 4800, for packages of component goods or services. In one 
embodiment, the package CPO management system 4500 deconstructs or breaks up an 
overall package CPO into component CPOs which are individually offered to sellers. 
The package CPO management system 4500 processes the individual component CPOs 
associated with each package CPO to determine whether one or more sellers, utilizing 

30 seller interfaces 4801-4806, are willing to accept each of the individual components of a 
given package CPO. As discussed further below, if each of the individual component 
CPOs of a given package CPO are accepted by one or more sellers, the package CPO 
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management system 4500 binds the buyer, on behalf of each of the accepting sellers, to 
purchase the entire package. In this manner, a legally binding contract is formed. 

As used herein, a package CPO is a binding offer containing one or more 
conditions submitted by a buyer for the purchase of a package of component goods or 
5 services or both, such as air travel, hotel and car rental, at a buyer-defined price. In the 
illustrative travel embodiment, the buyer-defined conditions for a package CPO would 
generally include overall price and itinerary parameters, such as the origin and 
destination cities; acceptable dates and times of travel; and desired class of service for 
each individual component. In addition, a buyer may optionally provide more detailed 

10 specifications for one or more individual components of an overall package CPO, such 
as whether connecting flights or stopovers are acceptable to the buyer for the airline 
portion of a travel -related package CPO, or a preferred provider for one or more 
individual component goods or services. 

According to one feature of the present invention, the package CPO 

15 management system 4500 preferably deconstructs an overall package CPO into 
component CPOs which are individually offered to sellers. In an alternate embodiment, 
the package CPO management system 4500 provides the overall package CPO to each 
seller, with sellers being able to separately accept each component of the package CPO. 
It is noted that the individual components of a package CPO can be for identical 

20 products. For example, a buyer can submit a purchase offer for six (6) general 
admission tickets to a particular sporting event. The package CPO management system 
4500 can provide the purchase offer to sellers as an integral CPO for six tickets which 
may only be accepted by one seller. Alternatively, the package CPO management 
system 4500 can deconstruct the overall package CPO for six tickets into a number of 

25 component CPOs for one or more tickets which are individually offered to sellers. In 
one implementation, an overall package CPO for bulk goods can be deconstructed into 
component CPOs which are optimized into units which are most likely to be accepted. 
In the above ticket example, the package CPO management system 4500 can 
decompose the request for six tickets into three component CPOs for two tickets each, 

30 assuming that most sellers are looking to sell pairs of tickets. 

In one preferred embodiment, the package CPO management system 
4500 reserves a margin off of the total offer price, before calculating the offer price for 
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each component CPO. The reserved margin amount may be determined based on the 
likelihood that all components of the overall package will be bound. In this manner, the 
margins mitigate the risk incurred by the package CPO management system 4500 as a 
result of a failure to bind all components of a package CPO. 

As discussed further below in conjunction with Figure 56, the package 
CPO management system 4500 can utilize the reserved margin or portions thereof to 
increase the offer price of one or more component CPOs that remain unaccepted by 
sellers. For example, if a buyer were to submit an offer for a vacation package with a 
total cost not to exceed one thousand dollars ($1,000.00), the package CPO 
management system 4500 may retain a one hundred dollar margin ($100), or ten percent 
(10%), to utilize if components of the desired package cannot be bound with the offer 
prices allocated from the initial $900, If, however, the package CPO management 
system 4500 is successful in binding the entire package with the initially allocated $900, 
then the package CPO management system 4500 can retain the $100 margin as profit, 
return the margin to the buyer, or place the unused margin in a fund to help bind the 
component CPOs of other package CPOs. 

In order to calculate an offer price for each component CPO, the package 
CPO management system 4500 preferably initially determines the total market price of 
the package based on the market price of each individual component good or service 
within the package. The package CPO management system 4500 then calculates an 
offer price for each component CPO based on the total price offered by the buyer for the 
entire package, as adjusted by the reserved margin, if appropriate, multiplied by the 
ratio of the market price of the respective component CPO to the total market price of 
the package. For example, if a buyer submits an offer for a travel package consisting of 
air travel, hotel accommodations and a car rental, with a total cost for the package not to 
exceed one thousand dollars ($1,000.00), and with each component item having a 
market price of $420, $400 and $250, respectively, the package would have a total 
market price of $1070. If a $100 margin is initially retained by the package CPO 
management system 4500, the $900 adjusted package CPO price would be allocated to 
the individual component CPOs as follows based on the market prices: $360 (40%) for 
airline tickets, $333 (37%) for hotel accommodations and $207 (23%) for car rental. 
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The package CPO management system 4500 then processes the 
individual component CPOs to determine whether one or more sellers are willing to 
accept each of the individual component CPOs of the overall package CPO. If 
successful, the package CPO management system 4500 binds the buyer, on behalf of 
5 each of the accepting sellers, to purchase the entire package. As discussed further 
below, as each individual component CPO is accepted by a seller, the package CPO 
management system 4500 preferably enters a "pre-bind" agreement with the seller, 
whereby the component good or service is reserved for a predefined time period to 
permit the package CPO management system 4500 to complete the processing of the 

10 remaining active component CPOs. A seller who accepts a component CPO may permit 
the package CPO management system 4500, for example, a two-week period within 
which the package CPO management system 4500 must complete the package. It is 
noted that such a limited predefined "pre-bind" period protects sellers from reserving a 
product that cannot be later sold. 

15 In an alternate implementation, the package CPO management system 

4500 can enter binding agreements with each seller who elects to accept a component 
CPO. In this implementation, if parts of the package were bound, and others were not at 
the time of expiration, the package CPO management system 4500 could fund the 
difference to complete the unaccepted components of the package at or near market 

20 prices, in a further alternate implementation, the package CPO management system 
4500 can provide component CPOs to sellers in a particular serial order, based on the 
likelihood that each component of the package will bind. 

In addition, a seller can preferably be ensured that the package CPO 
management system 4500 could not continue shopping an accepted component CPO to 

25 the seller s competitors after a prc-bind is obtained by encrypting the initial pre-bind. 
For example, a seller who pre-binds a given component CPO can encrypt their 
identifying characteristics before transmitting their acceptance to the package CPO 
management system 100 so that the package CPO management system 4500 can 
identify the seller's industry, such as airline, and authorization to accept offers, but 

30 could not identify the seller's specific identity until the entire package was complete. 

Although the package CPO management system 4500 is illustrated 
herein as a system for processing travel-related package CPOs, the package CPO 
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management system 4500 could be utilized to process packages of any component 
goods or services or both, such as automobiles and related insurance, computers and 
related peripheral equipment, or bulk goods, as would be apparent to a person of 
ordinary skill. 

5 PACKAGE CPO MANAGEMENT SYSTEM 

As shown in Figure 45, the package CPO management system 4500 
preferably includes a central controller 4600 and one or more secured servers 4700, for 
communicating with one or more buyer or seller interfaces 4800-4806. The package 
CPO management system 4500 may provide a given component CPO to selected sellers 

10 based on the industry associated with the component CPO or other predefined screening 
criteria, as shown in Figure 45, so that sellers only obtain component CPOs that they 
may be interested in or are authorized to screen. Alternatively, the package CPO 
management system may provide all component CPOs to all sellers for screening. 

According to one feature of the present invention, the package CPO 

15 management system 4500 preferably provides an optional agency feature that permits 
the package CPO management system 4500 to accept or reject a given component CPO 
on behalf of certain agency-based sellers who have delegated such authority to the 
package CPO management system 4500. Thus, the package CPO management system 
4500 preferably (i) evaluates component CPOs on behalf of certain agency-based sellers 

20 who have delegated authority to the package CPO management system 4500 to accept 
or reject a given component CPO, and (ii) permits broadcast-based sellers to evaluate 
component CPOs independently. Thus, the package CPO management system 4500 can 
preferably provide one or more component CPOs of a received package CPO to each 
broadcast-based seller, for the seller to independently determine whether or not to 

25 accept a given component CPO. It is noted that the package CPO management system 
4500 can provide a component CPO to each appropriate broadcast-based seller, for 
example, by means of a broadcast transmission, or by means of posting the component 
CPO, for example, on an electronic bulletin board accessible by each broadcast-based 
seller. Alternatively, the package CPO management system 4500 can evaluate one or 

30 more component CPOs of a received package CPO against a number of CPO rules 
defined by one or more agency-based sellers, to decide on behalf of an agency-based 
seller to accept or reject a given component CPO. Thus, the package CPO management 
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system 4500 can determine if one or more sellers accepts a given component CPO by 
providing the component CPO to each seller and receiving an acceptance or rejection, or 
by applying the component CPO to the CPO rules to render a decision to either accept, 
reject or counter a component CPO on behalf of a particular seller. 

As discussed further below, a CPO rule is a set of restrictions defined by 
a given agency-based seller, such as seller 4804, to define a combination of such 
restrictions for which the seller is willing to accept a predefined minimum price. In one 
embodiment, the CPO rules are generated by the revenue management system, yield 
management system, or profit management system of the respective agency-based 
seller, or by any system that controls and manages inventory. For a more detailed 
discussion of CPO rules, the manner in which they are generated and related security 
issues, see U.S. Patent Application Serial No. 08/889,319. entitled Conditional Purchase 
Offer Management System, filed July 8, 1997, the parent application to the present 
invention, which is incorporated by reference herein. Generally, the revenue 
15 management system, for example, will employ a CPO rules generation process to 
generate CPO rules by evaluating current inventory, pricing and revenue information, as 
well as historical patterns and external events, to forecast future travel. 

For example, a CPO rule for a given agency-based airline can specify 
that the airline will accept any component CPO for travel between Newark, New Jersey 
20 (EWR) and Orlando, Florida (MCO) during the month of October. 1997, provided that 
(i) the customer travels between Tuesday and Thursday, (ii) the tickets are booked 
within 21 days of departure, (iii) the price is at least $165 per ticket, (iv) K-class 
inventory is available on all flight segments of the customer s itinerary, and (v) there are 
at least two (2) passengers travelling together. 
25 As discussed further below in conjunction with Figure 47, each secured 

server 4700 may be associated with one or more agency-based sellers and each server 
4700 stores, among other things, the CPO rules defined by any associated agency-based 
sellers, such as sellers 4804 and 4806. Each secured server 4700 may be remotely 
located from the central controller 4600, as shown in Figure 45, or may be integrated 
30 with the central controller 4600. In one remote embodiment, the secured server 4700 
associated with each agency-based seller may be physically located at a processing 
facility secured by the particular seller, or at the physical location of a third party. 
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As discussed further below, each buyer contacts the package CPO 
management system 4500, for example, by means of telephone, facsimile, online access, 
e-mail, in-person contact or through an agent, and provides the package CPO 
management system 4500 with the terms of their package CPO. It is noted that each 
buyer may employ a general-purpose computer, such as the buyer interface 4800, 
discussed below in conjunction with Figure 48, for communicating with the package 
CPO management system 4500. The general-purpose computer of each buyer is 
preferably comprised of a processing unit, a modem, memory means and any software 
required to communicate with the package CPO management system 4500. 

Once the terms of the package CPO have heen received by the package 
CPO management system 4500, the central controller 4600 will execute a package CPO 
posting process 5500, discussed below in conjunction with Figures 55a through 55c, to 
deconstruct the overall package CPO into component CPOs, and thereafter (i) provide 
each component CPO to the appropriate broadcast-based sellers and (ii) evaluate each 
component CPO against the appropriate CPO rules of each appropriate agency-based 
seller. In addition, once the component CPOs have been posted, the package CPO 
management system 4500 will preferably periodically execute a package CPO 
monitoring process 5600, discussed further below in conjunction with Figures 56a 
through 56c, to determine if each component CPO of an overall package CPO is 
accepted by an appropriate seller. If each of the individual component CPOs of a given 
package CPO are accepted by one or more sellers, the package CPO management 
system 4500 notifies the buyer, on behalf of each of the accepting sellers, that he has 
been bound to purchase the entire package with the appropriate restrictions which meet 
the conditions defined by the buyer. 

The package CPO management system 4500 and buyer and seller 
interfaces 4800-4806 (collectively, the "nodes") preferably transmit digitally encoded 
data and other information between one another. The communication links between the 
nodes preferably comprise a cable, fiber or wireless link on which electronic signals can 
propagate. For example, each node may be connected via an Internet connection using 
a public switched telephone network (PSTN), such as those provided by a local or 
regional telephone operating company. Alternatively, each node may be connected by 
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dedicated data lines, cellular, Personal Communication Systems ("PCS"), microwave, or 
satellite networks. 

Figure 46 is a block diagram showing the architecture of an illustrative 
central controller 4600, The central controller 4600 preferably includes certain standard 

5 hardware components, such as a central processing unit (CPU) 4605, a random access 
memory (RAM) 4610, a read only memory (ROM) 4620, a clock 4625, a data storage 
device 4630, an operating system 4650, a payment processor 4660 and a network 
interface 4680. The CPU 4605 is preferably linked to each of the other listed elements, 
cither by means of a shared data bus, or dedicated connections, as shown in Figure 46. 

10 The CPU 4605 may be embodied as a single commercially available 

processor, such as Intel's Pentium 100 MHz P54C microprocessor, Motorola's 120 MHz 
PowerPC 604 microprocessor or Sun Microsystems 166 MHz UltraSPARC- 1 
microprocessor. Alternatively, the CPU 4605 may be embodied as a number of such, 
processors operating in parallel. 

15 The ROM 4620 and/or data storage device 4630 are operable to store one 

or more instructions, discussed further below in conjunction with Figures 55 and 56, 
which the CPU 4605 is operable to retrieve, interpret and execute. The payment 
processor 4660 preferably implements known processes to accomplish the transfer of 
required payments, charges and debits, between the sellers and buyers, by means of a 

20 conventional electronic funds transfer (EFT) network. In particular, as discussed below 
in conjunction with Figure 56, the package CPO monitoring process 5600 preferably 
transmits the credit card information associated with a given buyer to the credit card 
issuer for payment, if a package is actually purchased by the buyer. The processing of 
such accounting transactions are preferably secured in a conventional manner, for 

25 example, using well-known cryptographic techniques. 

The CPU 4605 preferably includes a control unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as, for example, a stackable 
cache or a plurality of registers, in a known manner. The control unit is operable to 
retrieve instructions from the data storage device 4630 or ROM 4620. The ALU is 

30 operable to perform a plurality of operations needed to carry out instructions. The CPU 
local memory storage device is operable to provide high-speed storage used for storing 
temporary results and control information. 
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As discussed further below in conjunction with Figures 49 through 53, 
respectively, the data storage device 4630 includes a buyer database 4900. a seller 
database 5000, a package CPO database 5100, a component CPO database 5200 and a 
market price database 5300. The buyer database 4900 preferably stores information on 
each buyer of the package CPO management system 4500, including biographical 
information and billing information, such as a credit card number. The seller database 
5000 preferably stores information on each seller which is registered with the package 
CPO management system 4500 to sell component goods or services to package CPO 
buyers, including identifier and name information. The package CPO database 5100 
preferably contains a record of each package CPO being processed by the package CPO 
management system 4500, including an indication of the component CPOs within each 
package CPO and the associated status. The component CPO database 5200 preferably 
contains a record of each component CPO being processed by the package CPO 
management system 4500, including the terms of each component CPO and the 
associated status. Finally, the market price database 5300 preferably stores market price 
information for each component good or service processed by the package CPO 
management system 4500. 

In addition, the data storage device 4630 includes a package CPO posting 
process 5500 and a package CPO monitoring process 5600, discussed further below in 
conjunction with Figures 55 and 56, respectively. Generally, the package CPO posting 
process 5500 deconstructs the package CPO into component goods or services, and 
thereafter (i) posts each component CPO to the appropriate broadcast-based sellers and 
(ii) evaluates each component CPO against the appropriate CPO rules of each agency- 
based seller. The package CPO monitoring process 5600 determines if each component 
CPO of a posted package CPO is accepted by an appropriate seller and, if accepted, 
provides buyer information to each accepting seller. In this manner, if each of the 
individual component CPOs of a given package CPO are accepted, the package CPO 
management system 4500 notifies the buyer, on behalf of each of the accepting sellers, 
that he has been bound to purchase the entire package. 

The network interface 4680 connects the central controller 4600 to the 
buyer and sellers, for example, by means of an Internet connection using the public 
switched telephone network (PSTN). The network interface 4680 preferably includes 
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multiple communication channels for simultaneously establishing a plurality of 
connections. 

Figure 47 is a block diagram showing the architecture of an illustrative 
secured server 4700. As previously indicated, the package CPO management system 

5 4500 may utilize one or more secured servers 4700, each supporting one or more 
agency-based sellers 4804, 4806. Each secured server 4700 preferably includes certain 
standard hardware components, such as a central processing unit (CPU) 4705, a random 
access memory (RAM) 4710, a read only memory (ROM) 4720, a clock 4725, a data 
storage device 4730, and a communications port 4740. Each of these components may 

10 be identical to those described above in conjunction with Figure 46. 

As previously indicated, in one embodiment, the CPO rules may be 
stored in a secure database to maintain the integrity and confidentiality of the highly 
sensitive information included in each CPO rule. Thus, the secured server 4700 
preferably uses a secure database, such as the products commercially available from 

15 Oracle, Informix or IBM. 

As discussed further below in conjunction with Figure 54, the data 
storage device 4730 includes a secured seller rules database 5400. The secured seller 
rules database 5400 preferably maintains the CPO rules for the one or more agency- 
based sellers associated with the secured server 4700. As previously indicated, the 

20 secured seller rules database 5400 may be stored in an encrypted format to maintain the 
integrity and confidentiality of the highly sensitive information included in the CPO 
rules. In addition, the data storage device 4730 includes a component CPO rule 
evaluation process 5700, discussed further below in conjunction with Figure 57. 
Generally, the component CPO rule evaluation process 5700 is a subroutine executed by 

25 the package CPO posting process 5500, which receives a component CPO and 
compares the CPO against the rules of one or more agency-based sellers to generate a 
response on behalf of the sellers to the given component CPO. 

The secured server 4700 may optionally maintain an audit trail for each 
component CPO that is processed by the package CPO management system 4500. For a 

30 discussion of a suitable audit system, see the parent application to the present invention, 
incorporated by reference herein above. 
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The communications port 4740 connects the secured server 4700 to the 
central controller 4600. The communications port 4740 preferably includes multiple 
communication channels for simultaneously establishing a plurality of connections. 

Figure 48 is a block diagram showing the architecture of an illustrative 
buyer or seller interface 4800-4806. The interface 4800 preferably includes certain 
standard hardware components, such as a centra! processing unit (CPU) 4808, a random 
access memory (RAM) 4810, a read only memory (ROM) 4820, a clock 4825, a data 
storage device 4830, and a communications port 4840. Each of these components may 
be identical to those described above in conjunction with Figure 46. In addition, the 
interface 4800 preferably includes a video monitor 4850 and related video driver 4860, 
and an input device 4870, such as a keyboard or mouse. 

The data storage device 4830 preferably includes a message database 
4880 for storing messages required by the respective buyer or seller interface 4800-4806 
to communicate with the central controller 4600 of the package CPO management 
system 4500. The communications port 4840 connects the interface 4800 to the central 
controller 4600 or the secured server 4700. for broadcast-based and agency-based 
sellers, respectively. 

Figure 49 illustrates an exemplary buyer database 4900 that preferably 
stores information on each buyer of the package CPO management system 4500, 
including biographical information and billing information, such as a credit card 
number. The buyer database 4900 maintains a plurality of records, such as records 
4905-4915, each associated with a different buyer. For each buyer identifier in field 
4920, the buyer database 4900 includes the corresponding buyer name and address in 
fields 4925 and 4930, respectively, and credit card number in field 4935. In addition, 
the buyer database 4900 preferably includes an indication of the CPOs associated with 
the buyer in field 4940, which may be package CPOs as described herein or general 
CPOs as described in the parent application to the present invention. The identifier 
stored in field 4920 may be utilized, for example, to index a historical database (not 
shown) of previous purchases and CPOs associated with the buyer. 

Figure 50 illustrates an exemplary seller database 5000 which preferably 
stores information on each seller which is registered with the package CPO management 
system 4500 to sell component goods or services to package CPO buyers, including 
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identifier and name information. The seller database 5000 maintains a plurality of 
records, such as records 5005-5030, each associated with a different seller. For each 
seller identifier listed in field 5035, the seller database 5000 includes the corresponding 
seller name in field 5040. In addition, the seller database 5000 preferably records a 

5 tracking number in field 5045 for any CPOs associated with each seller. It is noted that 
the information recorded in field 5045 could be similarly recorded by including a seller 
ID field in the package CPO database 5100, discussed below. 

Figure 51 illustrates a package CPO database 5100 which preferably 
contains a record of each package CPO being processed by the package CPO 

10 management system 4500, including an indication of the component CPOs within each 
package CPO and the associated status. The package CPO database 5100 maintains a 
plurality of records, such as records 5105-5110, each associated with a different 
package CPO. For each package CPO listed in field 5120, the package CPO database 
5100 includes the status and original offer price in fields 5125 and 5130, respectively. 

15 In addition, the package CPO database 5100 preferably records the margin factor, 
remaining margin, adjusted package CPO price and per-allocation-margin percentage in 
fields 5135 through 5150, respectively. The manner in which the margin variables are 
processed by the package CPO management system 4500 are discussed below in 
conjunction with Figure 56. The posting and expiration dates of the package CPO, as 

20 well as the total posting duration period and posting time required for each margin 
allocation are stored in fields 5155 through 5170, respectively. The individual 
component goods or services within each package CPO are optionally identified in field 
5175, and the conditions and component numbers associated with each component are 
set forth in fields 5180 and 5185. It is noted that the information recorded in fields 5175 

25 and 5180 could alternatively be retrieved from the component CPO database 5200 using 
the component CPO numbers recorded in field 5185. Finally, an identifier of the buyer 
associated with each package CPO is preferably recorded in field 5190. 

Figure 52 illustrates an exemplary component CPO database 5200 which 
preferably contains a record for each component CPO being processed by the package 

30 CPO management system 4500, including the terms of the component CPO and the 
associated status. The component CPO database 5200 maintains a plurality of records, 
such as records 5205 through 5230, each associated with a different component CPO 
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being processed by the system 4500. For each component CPO identified by 
component CPO number in field 5240, the component CPO database 5200 includes the 
status or expiration date for pre-bound component CPOs in field 5245, as well as the 
corresponding subject, price and conditions associated with the component CPO in 
5 fields 5250 through 5260, respectively. Finally, an identifier of the buyer associated 
with each component CPO is preferably recorded in field 5265. 

Figure 53 illustrates an exemplary market price database 5300 that 
preferably stores market price information for each component good or service 
processed by the package CPO management system 4500. As discussed further below 
10 in conjunction with Figure 55, the package CPO posting process 4500 preferably 
utilizes the market price information to allocate the overall package price to each 
component good or service. The market price database 5300 maintains a plurality of 
records, such as records 5305 through 5345, each associated with a different component 
good or service processed by the system 4500. For each component good or service 
15 identified in field 5360, the market price database 5300 identifies the available quality 
or service levels for each good or service in field 5365, as well as the corresponding 
market price set forth in field 5375, for each time period indicated in field 5370. It is 
noted that the market price for each service level of round trip airline travel is preferably 
recorded for each originating and destination city pair (O & D Pair). 
20 As Previously indicated, the secured server 4700 preferably maintains 

one or more secured seller rules databases 5400 to store the CPO rules for the one or 
more agency-based sellers associated with the secured server 4700. An example of a 
secured seller rules database 5400 is shown in Figure 54a for an agency -based airline 
and in Figure 54b for an agency -based hotel. 
25 Figure 54a illustrates an exemplary secured airline rules database 5400 

which preferably maintains the CPO rules for one or more agency-based airlines 
associated with a particular secured server 4700. As previously indicated, the secured 
airline rules database 5400 may be stored in an encrypted format to maintain the 
integrity and confidentiality of the highly sensitive information included in the CPO 
30 rules. The secured airline rules database 5400 maintains a plurality of records, such as 
records 5402 and 5404, each associated with a different CPO rule. For each CPO rule 
identified by rule number in field 54 1 0,' the secured airline rules database 5400 includes 
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the associated restrictions defined by the respective agency-based airline in fields 5412 
through 5444. 

Figure 54b illustrates an exemplary secured hotel rules database 5450 
which preferably maintains the CPO rules for one or more agency-based hotels 
5 associated with a particular secured server 4700. As previously indicated, the secured 
hotel rules database 5450 may be stored in an encrypted format to maintain the integrity 
and confidentiality of the highly sensitive information included in the CPO rules. The 
secured hotel rules database 5450 maintains a plurality of records, such as records 5452 
through 5456, each associated with a different CPO rule. For each CPO rule identified 
10 by rule number in field 5460, the secured hotel rules database 5450 identifies the 
applicable hotel sites in field 5465 and includes the associated restrictions defined by 
the respective agency-based hotel in fields 5470 through 5490. 

As discussed above, the central controller 4600 preferably executes a 
package CPO posting process 5500, shown in Figures 55a through 55c, to deconstruct 
15 the package CPO into component goods or services, and thereafter (i) post each 
component CPO to the appropriate broadcast-based sellers and (ii) evaluate each 
component CPO against the appropriate CPO rules of each agency-based seller. As 
illustrated in Figure 55a, the package CPO posting process 5500 begins the processes 
embodying the principles of the present invention during step 5505, when a buyer 
20 submits a CPO for a package of component goods or services. 

Thereafter, the central controller 4600 will receive the conditions 
associated with the package CPO from the buyer, including a description of each 
component good or service, and an identifier of a general purpose account, such as a 
credit or debit card account from which funds may be paid during step 5510, and then 
25 receive the price and expiration date for the package CPO from the buyer during step 
55 15. In this manner, the offer is guaranteed with a general purpose account, for 
example, using a line of credit on a credit card account. Appropriate legal language is 
preferably displayed or read to the buyer during step 5520 to form a binding package 
CPO. A package CPO number is generated during step 5525, and the package CPO 
30 information, including the buyer identifier, package CPO price and expiration date, and 
conditions for the component goods or services, is then entered into the package CPO 
database 5100 during step 5530. 
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being processed by the system 4500. For each component CPO identified by 
component CPO number in field 5240, the component CPO database 5200 includes the 
status or expiration date for pre-bound component CPOs in field 5245, as well as the 
corresponding subject, price and conditions associated with the component CPO in 
Fields 5250 through 5260, respectively. Finally, an identifier of the buyer associated 
with each component CPO is preferably recorded in field 5265. 

Figure 53 illustrates an exemplary market price database 5300 that 
preferably stores market price information for each component good or service 
processed by the package CPO management system 4500. As discussed further below 
in conjunction with Figure 55, the package CPO posting process 4500 preferably 
utilizes the market price information to allocate the overall package price to each 
component good or service. The market price database 5300 maintains a plurality of 
records, such as records 5305 through 5345, each associated with a different componen. 
good or service processed by the system 4500. For each component good or service 
identified in field 5360, the market price database 5300 identifies the available quality 
or service levels for each good or service in field 5365, as well as the corresponding 
market price set forth in field 5375, for each time period indicated in field 5370. It is 
noted that the market price for each service level of round trip airline travel is preferably 
recorded for each originating and destination city pair (O & D Pair). 

As previously indicated, the secured server 4700 preferably maintains 
one or more secured seller rules databases 5400 to store the CPO rules for the one or 
more agency-based sellers associated with the secured server 4700. An example of a 
secured seller rules database 5400 is shown in Figure 54a for an agency -based airline 
and in Figure 54b for an agency -based hotel. 

Figure 54a illustrates an exemplary secured airline rules database 5400 
which preferably maintains the CPO rules for one or more agency-based airlines 
associated with a particular secured server 4700. As previously indicated, the secured 
airline rules database 5400 may be stored in an encrypted format to maintain the 
integrity and confidentiality of the highly sensitive information included in the CPO 
rules. The secured airline rules database 5400 maintains a plurality of records, such as 
records 5402 and 5404, each associated with a different CPO rule. For each CPO rule 
identified by rule number in field 5410, the secured airline rules database 5400 includes 
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the associated restrictions defined by the respective agency-based airline in fields 5412 
through 5444. 

Figure 54b illustrates an exemplary secured hotel rules database 5450 
which preferably maintains the CPO rules for one or more agency-based hotels 
5 associated with a particular secured server 4700. As previously indicated, the secured 
hotel rules database 5450 may be stored in an encrypted format to maintain the integrity 
and confidentiality of the highly sensitive information included in the CPO rules. The 
secured hotel rules database 5450 maintains a plurality of records, such as records 5452 
through 5456, each associated with a different CPO rule. For each CPO rule identified 
10 by rule number in field 5460, the secured hotel rules database 5450 identifies the 
applicable hotel sites in field 5465 and includes the associated restrictions defined by 
the respective agency-based hotel in fields 5470 through 5490. 

As discussed above, the central controller 4600 preferably executes a 
package CPO posting process 5500, shown in Figures 55a through 55c, to deconstruct 
15 the package CPO into component goods or services, and thereafter (i) post each 
component CPO to the appropriate broadcast-based sellers and (ii) evaluate each 
component CPO against the appropriate CPO rules of each agency-based seller. As 
illustrated in Figure 55a, the package CPO posting process 5500 begins the processes 
embodying the principles of the present invention during step 5505, when a buyer 
20 submits a CPO for a package of component goods or services. 

Thereafter, the central controller 4600 will receive the conditions 
associated with the package CPO from the buyer, including a description of each 
component good or service, and an identifier of a general purpose account, such as a 
credit or debit card account from which funds may be paid during step 5510, and then 
25 receive the price and expiration date for the package CPO from the buyer during step 
55 15. In this manner, the offer is guaranteed with a general purpose account, for 
example, using a line of credit on a credit card account. Appropriate legal language is 
preferably displayed or read to the buyer during step 5520 to form a binding package 
CPO. A package CPO number is generated during step 5525, and the package CPO 
30 information, including the buyer identifier, package CPO price and expiration date, and 
conditions for the component goods or services, is then entered into the package CPO 
database 5100 during step 5530. 
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As previously indicated, the package CPO management system 4500 
preferably reserves a margin off of the total package offer price, before calculating the 
offer price for each component CPO. Thus, an appropriate margin is calculated during 
step 5535 by multiplying the package CPO price by the margin factor recorded in the 
5 package CPO database 5100. Thereafter, the calculated margin is recorded in the 
"remaining margin" field 5140 of the package CPO database 5100 during step 5540 
(Figure 55b). The adjusted CPO price is then calculated by subtracting the calculated 
margin from the original total package offer price, which is then entered into the 
package CPO database 5100 during step 5545. The status of the package CPO is set to 

10 "active" in field 5 1 25 of the package CPO database 5 1 00 during step 5550. 

The market price of each component good or service in the package CPO 
is retrieved during step 5555 from the market price database 5300. The market price of 
the overall package CPO is calculated during step 5560 by adding the market price of 
each individual component CPO in the overall package. The individual CPO prices for 

15 each component CPO are then calculated during step 5565, for example, by allocating 
the adjusted package CPO price, as calculated during step 5545, in accordance with the 
ratio of the market price of the respective component good or service to the total market 
price. 

A CPO number is then generated for each component CPO during step 
20 5570 and recorded in the "component CPO numbers" field of the package CPO database 
5100 during step 5575 (Figure 55c). A new record is created in the component CPO 
database 5200 for each component CPO during step 5580, before each component CPO 
is provided to each broadcast-based seller and the component CPO rule evaluation 
process 5700 is executed for each agency-based seller during step 5590. Program 
5 control terminates during step 5595. 

As discussed above, the central controller 4600 preferably executes a 
package CPO monitoring process 5600, shown in Figures 56a through 56c, to determine 
if each component CPO of a posted package CPO has been accepted by an appropriate 
seller and, if accepted, provides buyer information to each accepting seller. In this 
0 manner, if each of the individual component CPOs of a given package CPO are 
accepted, the package CPO management system 4500 notifies and binds the buyer, on 
behalf of each of the accepting sellers, to purchase the entire package. The package 
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CPO monitoring process 5600 may be periodically executed to determine the status of 
each component CPO, or executed continuously. 

As illustrated in Figure 56a, the package CPO monitoring process 5600 
begins the processes embodying the principles of. the present invention during step 
5 5605, by performing a test to determine if all or the component CPOs within a given 
package CPO have been pre-bound at currently posted prices. It is noted that in the 
illustrative embodiment, the first seller to accept a given component CPO is awarded the 
component CPO. For a discussion of other mechanisms for determining which seller 
among a plurality of accepting sellers should be awarded a component CPO, see the 

10 parent application to the present invention, incorporated by reference herein above. If it 
is determined during step 5605 that all of the component CPOs within a given package 
CPO have been pre-bound at currently posted prices, then buyer identification 
information, including the buyer's name, address and credit card account number, is 
retrieved from the buyer database 4900 during step 5650. Thereafter, the buyer 

15 identification number is transmitted to each seller who accepted a component CPO 
during step 5655. The package CPO monitoring process 5600 transmits the merchant 
identifier of the package CPO management system 4500, together with the buyer's 
credit card account number, a billing descriptor and the purchase amount for the 
package CPO to the credit card issuer for payment authorization during step 5660, via a 

20 conventional credit card authorization network. 

The status field 5125 of the package CPO database 5100 is updated 
during step 5665 to indicate that the respective package CPO was completed, before 
program control terminates during step 5670. 

If, however, it was determined during step 5605 that all of the component 

25 CPOs within a given package CPO have not. been pre-bound at currently posted prices, 
then the expiration date of the package CPO is retrieved from field 5160 of the package 
CPO database 5 100 during step 5610 (Figure 56b). A test is then performed during step 
5615 to determine if the package CPO has expired. If it is determined during step 5615 
that the package CPO has expired, without each component being pre-bound, then the 

30 package CPO monitoring process 5600 communicates (1) termination of any pre-bind 
agreements for component CPOs within the expired package CPO which were accepted 
by one or more sellers to the respective sellers during step 5635; and (1 1) expiration of 
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the package CPO to the respective buyer during step 5640. In an alternate embodiment, 
the buyer can be invited to resubmit a revised package CPO if the original package CPO 
is not accepted. In addition, the package CPO management system 4500 might attempt 
to compile a counteroffer for the buyer, based on acceptances of individual components 
5 received by the package CPO management system 4500. Thereafter, program control 
terminates during step 5645. 

If, however, it is determined during step 5615 that the package CPO has 
not expired, then the package CPO monitoring process 5600 will adjust the status field 
5125 of the package CPO database 5100 during step 5620 to indicate the percentage of 

10 the overall package CPO which is currently pre-bound, for example, by accessing the 
package CPO database 5100 to identify the number of components in the package CPO, 
and identifying the number of components which are currently pre-bound. Thereafter, 
the "total posting duration" parameter is retrieved from field 5165 of the package CPO 
database 5100 during step 5625, which is then multiplied by the "posting time required 

15 for each margin allocation" parameter set forth in field 5 1 70. 

A test is then performed during step 5630 to determine if the package 
CPO has been active for the posting time required to allocate additional margin to 
increase the price of each component CPO which has not yet been pre-bound. If it is 
determined during step 5630 that the package CPO has not been active for the posting 

20 time required to allocate additional margin, then program control returns to step 5605 
(Figure 56a) and continues processing in the manner described above. If, however, it is 
determined during step 5630 that the package CPO has been active for the posting time 
required to allocate additional margin, then the percent composition of each remaining 
active component CPO is calculated during step 5675 (Figure 56c) relative to the total 

25 price of all remaining active component CPOs. 

The "per allocation margin percentage" is then retrieved during step 5680 
from field 5150 of the package CPO database 5100. The amount of margin to be 
allocated to remaining active component CPOs is then calculated during step 5682 by 
multiplying the retrieved "per allocation margin percentage" value by "remaining 

30 margin" value recorded in field 5140 of the package CPO database 5100. Thereafter, 
the allocable margin is applied to each remaining active component CPO in appropriate 
percentages during step 5684 by multiplying the price percentages of the remaining 



107 



WO 98/10361 



PCT/US97/15492 



active component GPOs (as determined during step 5675) by the calculated allocable 
margin amount. 

For example, if one component of a three component package is initially 
pre-bound at the originally posted price, and the remaining two components are not 

5 bound within the posting time required to allocate additional margin, then the package. 
CPO monitoring process 5600 preferably allocates part of the margin between the two 
remaining component CPOs. The amount allocated to each component CPO is 
preferably determined by their respective initially posted prices. Assume in the 
example discussed above, where a buyer submits an offer for a travel package 

0 consisting of air travel, hotel accommodations and a car rental, with a total cost for the 
package not to exceed one thousand dollars ($1,000.00), that the first component to 
prebind was the airline tickets at $360. Thus, the package CPO monitoring process 
5600 will allocate a portion of the remaining margin to the offer prices for the hotel and 
car rental component CPOs. In a preferred embodiment, since the hotel component 

5 CPO accounts for 62% of the total remaining CPO prices ($333/($333 + $207)), the 
offer price of the hotel component CPO is increased by 62%, or $31 , of the money taken 
from the margin ($50). Likewise, the car rental component CPO offer price would be 
increased by 38% or $19. If one or more components are again not bound for the 
posting time required to allocate additional margin, more of the margin is preferably 

0 allocated. 

The "remaining margin" recorded in field 5140 is adjusted during step 
5688 by subtracting the margin allocated in the previous step. Thereafter, during step 
5690, the remaining active CPOs with the newly adjusted prices are provided to 
broadcast-based sellers and the component CPO rule evaluation process 5700 is 

5 executed for each appropriate agency-based seller. Finally, program control returns to 
step 5605 (Figure 56a) and continues processing in the manner described above, until all 
component CPOs are pre-bound, or until the package CPO expires. In this manner, the 
offer prices are increased with additional allocated margin for each component CPO that 
remains unaccepted for each time period required to allocate additional margin. As 

0 discussed above, the package CPO posting process 5500 and the package CPO 
monitoring process 5600 each execute a component CPO rule evaluation process 
during steps 5590 and 5690, respectively, for agency-based sellers to compare the 
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component CPOs against the rules of one or more agency-based sellers to generate a 
response on behalf of the sellers to the given component CPO. An illustrative 
component CPO rule evaluation process 4700 is shown in Figure 57. In one 
embodiment, the component CPO rule evaluation process 5700 is customized for each 
agency-based seller, so that each evaluation process 5700 receives the component CPO 
record from the central controller 4600 in a standard format for comparison against the 
rules of the associated seller, and returns a standard response of the seller to the 
component CPO, such as "accept" or "reject." 

As shown in Figure 57. the component CPO rule evaluation process 5700 
initially identifies all CPO rules in the secured seller rules database 5000 which are 
pertinent to the component CPO during step 5710. Thereafter, during step 5720, the 
buyer defined conditions from the component CPO record in the component CPO 
database 5200 are then compared to the corresponding seller defined restrictions from 
the secured seller rules database 5000 during step 5720, for each CPO rule identified 
during the previous step. 

Thereafter, a test is performed during step 5730 to determine if the 
component CPO satisfies a CPO rule. If it is determined during step 5730 that the 
component CPO does not satisfy one CPO rule, then program control terminates during 
step 5770. If. however, it is determined during step 5730 that the component CPO does 
satisfy a CPO rule, then the component CPO number is retrieved from the component 
CPO database 5200 during step 5740, and then entered into the "CPO tracking number- 
field 5045 of the seller database 5000. The status of the component CPO in field 5245 
of the component CPO database 5200 is updated to "pre-bind completed" during step 
5760, before program control terminates during step 5770. In addition, a pre-bind 
expiration date can be added to field 5245, if mandated by the seller. 

CPO MANAGEMENT SYSTEM FOR TELEPHONE CALLS 
A further embodiment of the present invention, suitable for processing 
purchase offers for one or more telephone calls, is discussed below in conjunction with 
Figures 58 through 66. Figures 58A and 58B show a conditional purchase offer (CPO) 
management system 5800 for receiving and processing CPOs for telephone calls from 
one or more calling parties, such as calling party 5810. The CPO management system 
5800 processes the CPO to determine whether one or more long distance carriers, such 
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as interexchange carriers 5820-5824, are willing to accept a given CPO and complete a 
telephone call in accordance with restrictions defined by the calling party 5810. In the 
United States, for example, the interexchange carriers 5820-5824 may be AT&T, Sprint 
and MCI. As discussed further below, if an interexchange carrier 5820 accepts a given 

5 CPO, the CPO management system 5800 binds the calling party 5810 on behalf of the 
accepting interexchange carrier 5820, to form a legally binding contract. 

As used herein, a CPO is a binding offer containing one or more 
conditions, submitted by a calling party 5810 for the completion of one or more 
telephone calls, typically at a price defined by the calling party. In this manner, a 

10 calling party 5810 can preferably submit a CPO for an individual telephone call, a 
package of calls to one or more called parties 5830, or for a contract to provide 
telephone service for a predefined period of time. In the illustrative embodiment, the 
conditions defined by the calling party 5810 may include the telephone number to be 
called, the maximum price, one or more preferred carriers, if any, as well as any time 

15 limitations, such as a particular time-of-day or minimum call duration. The maximum 
price may preferably be specified by the calling party 5810 in terms of a price for a 
fixed period of time, such as ten dollars ($10) for a twenty (20) minute telephone call, or 
in terms of a rate-per-minute, such as fourteen cents per minute ($0.14/minute). 

CPO MANAGEMENT SYSTEM 

20 Figure 58A shows an illustrative network environment for 

interconnecting the CPO management system 5800 with one or more calling parties 
5810 and one or more interexchange carriers 5820-5824 who may route a call to a 
desired called party 5830. According to a feature of the present invention, a calling 
party 5810, desiring to call a called party 5830, typically identified by a Plain Old 

25 Telephone Service (POTS) telephone number, may submit an offer to the CPO 
management system 5800 for a telephone call in accordance with restrictions defined by 
the calling party. In one preferred implementation, the calling party 5810 uses a 
telephone set 5900, shown in Figure 59, to dial the telephone number assigned to the 
CPO management system 5800, such as a toll-free telephone number, or "800 number," 

30 before dialing the telephone number of the called party 5830 to provide the CPO 
management system 5800 with the terms of the CPO. Alternatively, the calling party 
5810 can initially contact the CPO management system 5800 by means of facsimile. 
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Once the calling party 5810 initially contacts the CPO management system 5800, the 
calling party 5810 then submits the terms of the CPO to the CPO management system 
5800, such as the maximum price for the call and the telephone number of the called 
party 5830. 

In a further variation, shown in Figure 58B. the calling party 58 10. can 
initially contact the CPO management system 5800 by means of online access or e-mail 
using a subscriber terminal 5815, such as a general-purpose computer, to access the 
Internet 5870. This online embodiment is particularly suited for a calling party 5810 
desiring to submit a CPO for a package of calls to one or more called parties 5830, or 
for a contract to provide telephone service for a predefined period of time. 

The terms of the CPO may optionally be displayed to the calling party 
5810 on the telephone set 5900, as shown in Figure 59. In addition, the telephone set 
5900 can be specially configured with software for transmitting a CPO to the CPO 
management system 5800 or directly to the interexchange carriers 5820. For example, a 
speed dial button of the telephone set 5900 can be programmed to automatically 
transmit the terms of a CPO to the CPO management system 5800 or directly to the 
interexchange carriers 5820. In this manner, the calling party 5810 would program the 
terms of a given CPO using the keypad and function keys on the telephone set 5900, 
and then initiate transmission of the CPO using the speed dial button. 

As shown in Figure 58A, when the calling party 5810 dials the telephone 
number assigned to the CPO management system 5800, a connection is typically first 
established to a local switch operator 5850, which is the telephone switching system, for 
example, of the local telephone company. The local switch operator 5850 in turn 
connects the calling party to the Public Switched Telephone Network (PSTN). The local 
switch operator 5850 is capable of establishing a connection between the calling party 
5810 and one of a number of interexchange carriers 5820-5824 over a communications 
link 5860, in a manner well-known in the telephony art. The interexchange carriers 
5820 may be, for example, providers of long distance carrier networks, including circuit 
and packet switched networks or combinations thereof, and the communications link 
5860 may be a cable, fiber or wireless link on which electronic signals can propagate. It 
is noted that with the increasing trend for long distance carriers to provide local 
telephone service in many areas, and vice versa, the distinction between the local switch 
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operator 5850 and the interexchange carriers 5820-5824 may become transparent. One 
or more of the interexchange carriers 5820 may be able to route a call between a given 
calling party 5810 and a desired called party 5830. For a more detailed discussion of 
the manner in which a connection is made between a given calling party 5810 and a 

5 desired called party 5830, over a long distance carrier network by an interexchange 
carrier 5820, see U.S. Patent Number 4,191,860, incorporated by reference herein. 

According to a feature of the present invention, the CPO management 
system 5800 preferably provides an optional agency feature that permits the CPO 
management system 5800 to accept or reject a given CPO on behalf of certain agency- 

10 based interexchange carriers 5820 who have delegated such authority to the CPO 
management system 5800. Thus, the CPO management system 5800 preferably (i) 
evaluates CPOs on behalf of certain agency-based interexchange carriers 5820 who 
have delegated authority for deciding to accept or reject a given CPO to the CPO. 
management system 5800; and (ii) permits broadcast-based interexchange carriers 5820 

15 to evaluate CPOs independently. Thus, the CPO management system 5800 can provide 
a CPO to each broadcast-based interexchange carrier 5820, for the interexchange carrier 
5820 to independently determine whether or not to accept a given CPO. It is noted that 
the CPO management system 5800 can provide a CPO to each broadcast-based 
interexchange carrier 5820, for example, by means of a broadcast transmission, or by 

20 means of posting the CPO, for example, on an electronic bulletin board accessible by 
each broadcast-based interexchange carrier 5820. 

In addition, the CPO management system 5800 can evaluate a CPO 
against a number of CPO rules defined by one or more agency-based interexchange 
carriers 5820, to decide on behalf of an agency-based interexchange carrier 5820 to 

25 accept or reject a given CPO. Thus, the CPO management system 5800 can determine if 
one or more carriers accepts a given CPO by providing the CPO to each carrier and 
receiving an acceptance or rejection, or by applying the CPO to the CPO rules to render 
a decision to either accept, reject or counter a CPO on behalf of a particular carrier. 

As discussed further below, a CPO rule is a set of restrictions defined by 

30 a given agency-based interexchange carrier 5820, to define a combination of such 
restrictions for which the interexchange carrier 5820 is willing to accept a commitment 
to complete one or more telephone calls. In a preferred embodiment, the CPO rules are 
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generated by some type of revenue management system, yield management system, or 
profit management system of the respective agency-based interexchange carrier 5820, 
or by any system that controls and manages network capacity. For a more detailed 
discussion of CPO rules, the manner in which they are generated and related security 
issues, see U.S. Patent Application Serial No. 08/889,319, entitled Conditional Purchase 
Offer Management System, filed July 8, 1997, the parent application to the present 
invention, which is incorporated by reference herein. Generally, the revenue 
management system, for example, will employ a CPO rules generation process to 
generate CPO rules by evaluating current network capacity, pricing and revenue 
information, as well as historical patterns and external events, to forecast future calling 
demand. 

Once the terms of a CPO have been received by the CPO management 
system 5800, a central server 6000, discussed below in conjunction with Figure .60. will 
execute a CPO management process 6500, discussed below in conjunction with Figures 
65a and 65b, to (i) provide each CPO to the interexchange carriers 5820 and (ii) to 
determine if the terms of the offer have been accepted by any interexchange carrier 
5820. Thereafter, the CPO management system 5800 or the accepting interexchange 
carrier 5820 notifies the calling party 5810 of the response of the interexchange carriers 
5820 and, if accepted, the calling party 5810 is bound to complete and pay for one or 
more calls having the appropriate restrictions which meet the conditions defined by the 
calling party 5810. 

The CPO management system 5800 may optionally maintain an audit 
trail for each CPO that is processed by the CPO management system 5800. For a 
discussion of a suitable audit system, see the parent application to the present invention, 
incorporated by reference herein above. 

According to a further feature of the invention, the CPO management 
system 5800 prevents calling parties 5810 from identifying the carrier's minimum price 
for the one or more telephone calls associated with a given CPO. For example, the CPO 
management system 5800 preferably does not disclose the carrier's minimum price to 
calling parties and optionally limits the number of CPOs that any calling party 58 10 can 
submit within a predefined time period. In addition, the binding nature of the present 
invention discourages calling parties 5810 from submitting CPOs merely to identify the 
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minimum price, since the calling party 5810 will be obligated to complete one or more 
telephone call(s) in accordance with the terms of the CPO. In alternate embodiments, 
the calling party 5810 can be charged a fee or a penalty if a call is not completed when 
at least one carrier 5820 has accepted the CPO, or the CPO management system 5800 

5 can, evaluate a rating of the calling party 5810 containing information regarding the 
likelihood that the calling party 5810 will complete one or more telephone calls 
corresponding to said CPO. For a more detailed description of a suitable rating system, 
see U.S. Patent Application Serial No. 08/811,349, filed March 4, 1997, entitled 
AIRLINE PRICE INQUIRY METHOD AND SYSTEM, assigned to the assignee of the 

10 present invention and incorporated by reference herein. In one embodiment, the 
evaluated rating comprises a ratio of completed calls to purchase offers by the customer 
5810. In this manner, the carriers 5820 can be confident that if the carrier accepts the 
calling party's offer, the calling party 5810 will complete the call(s) without using the 
information to ascertain the carrier's underlying level of price flexibility. 

15 Figure 60 is a block diagram showing the architecture of an illustrative 

CPO management central server 6000. The CPO management central server 6000 
preferably includes certain standard hardware components, such as a central processing 
unit (CPU) 6005, a random access memory (RAM) 6010, a read only memory (ROM) 
6020, a clock 6025, a data storage device 6030, and a communications port 6040. The 

20 CPU 6005 is preferably linked to each of the other listed elements, either by means of a 
shared data bus, or dedicated connections, as shown in Figure 60. The CPU 6005 may 
be embodied as a single commercially available processor, such as Intel's Pentium 100 
MHz P54C microprocessor, Motorola's 120 MHz PowerPC 604 microprocessor or Sun 
Microsystem's 166 MHz UltraSPARC-I microprocessor. Alternatively, the CPU 6005 

25 may be embodied as a number of such processors operating cooperatively. 

The ROM 6020 and/or data storage device 6030 are operable to store one 
or more instructions, discussed further below in conjunction with Figures 65 and 66, 
which the CPU 6005 is operable to retrieve, interpret and execute. For example, the 
ROM 6020 and/or data storage device 6030 preferably store processes to accomplish the 

30 transfer of required payments, charges and debits, between the calling parties 5810 and 
interexchange carriers 5820-5824. 
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The CPU 6005 preferably includes a control unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as, for example, a stackable 
cache or a plurality of registers, in a known manner. The control unit is operable to 
retrieve instructions from the data storage device 6030 or ROM 6020. The ALU is 
operable to perform a plurality of operations needed to carry out instructions. The CPU 
local memory storage device is operable to provide high-speed storage used for storing 
temporary results and control information. 

As discussed further below in conjunction with Figures 61 through 64, 
respectively, the data storage device 6030 preferably includes a customer database 
6100, a carrier database 6200, a rate database 6300, and a CPO database 6400. The 
customer database 6100 preferably stores information on each customer of the CPO 
management system 5800, including biographical information and an indication of the 
local telephone company serving each customer. The carrier database 6200 preferably 
stores information on each carrier which is registered with the CPO management system 
5800 to provide long distance telephone service to calling parties, including address 
information. The rate database 6300 preferably stores published rate information for 
each carrier identified in the carrier database 6200. Finally, the CPO database 6400 
preferably contains a record of each CPO being processed by the CPO management 
system 5800, including the terms of the CPO and the associated status. 

In an embodiment where the CPO management system 5800 provides an 
agency feature that permits the CPO management system 5800 to accept or reject a 
given CPO on behalf of certain agency-based interexchange carriers 5820 who have 
delegated such authority to the CPO management system 5800, the CPO management 
central server 6000 preferably includes a CPO rules database (not shown) for storing the 
CPO rules. The CPO rules may be stored in a secure database to maintain the integrity 
and confidentiality of sensitive information included in each CPO rule. 

In addition, the data storage device 6030 includes a CPO management 
process 6500, discussed further below in conjunction with Figures 65a and 65b, and an 
IVRU process 6600, discussed further below in conjunction with Figures 66a and 66b. 
Generally, the CPO management process 6500 receives each CPO from a calling party 
5810, provides the CPO to each appropriate interexchange carrier 5820 and thereafter 
determines if the terms of the offer have been accepted by any interexchange carrier 
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5820. The IVRU process 6600 is preferably invoked by the CPO management process 
6500 to receive the parameters of the CPO from the calling party 5810. 

The communications port 6040 connects the CPO management central 
server 6000 to the local switch operator 5850 and interexchange carriers 5820-5824. 
5 The communications port 6040 preferably includes multiple communication channels 
for simultaneously establishing a plurality of connections. 

DATABASES 

Figure 61 illustrates an exemplary customer database 6100 that 
preferably stores information on each customer (calling party) of the CPO management 

10 system 5800, including biographical information and an indication of the local 
telephone company serving each customer. The customer database 6100 maintains a 
plurality of records, such as records 6105-6125, each associated with a different 
customer. For each customer name listed in field 6140, the customer database 6100 
includes the customer's address in field 6145, the manner in which the customer is 

15 bound in field 6150, an indication of the local telephone company serving the customer 
in field 6155 and the customer's telephone number in field 6160. The telephone 
number stored in field 6160 may be utilized, for example, as a customer identifier to 
index a historical database (not shown) of previous transactions associated with the 
customer. 

20 As shown in field 6150, a given customer may be bound by a pre- 

existing written or electronic contract on file, which may, for example, authorize an 
accepting interexchange carrier 5820 to charge the calling party 5810 for a given call on 
the calling party's telephone statement or by means of a charge to a credit card, or other 
general-purpose account. As discussed below, the calling party 5810 may be billed for 

25 telephone calls completed in accordance with the present invention by the CPO 
management system 5800 or the local switch operator 5850, on behalf of the accepting 
interexchange carrier 5820, or directly by the accepting interexchange carrier 5820, in a 
conventional manner. 

In an implementation where a CPO obligates a calling party 5810 to 

30 achieve minimum usage for a predefined time period, for example, where a calling party 
5810 agrees to spend at least two hundred dollars ($200) over twelve (12) months to 
obtain a lower rate, the agreed upon terms can be immediately charged to a credit card, 
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or charged on a monthly basis. In addition, the credit card may not be charged unless 
the calling party 58 10 fails to meet the obligations of the CPO. For example, the calling 
party 5810 may be billed directly for calls as charges are incurred, and the remaining 
balance may be charged to the credit card account at the end of the agreed term. In 
5 addition, a calling party 5810 can be charged a penalty if the calling party 5810 does not 
agree to complete the call after the CPO is accepted by an interexchange carrier 5820. 

Figure 62 illustrates an exemplary carrier database 6200 which 
preferably stores information on each carrier which is registered with the CPO 
management system 5800 to provide long distance telephone service to calling parties, 

10 including address information. The carrier database 6200 maintains a plurality of 
records, such as records 6205-6225, each associated with a different carrier. For each 
carrier name listed in field 6240, the carrier database 6200 includes address information 
in field 6245. In addition, in an embodiment where the CPO rules of a given carrier arc 
stored in an encrypted format, or otherwise where secure transmissions are required, the 

15 cryptographic key of the associated carrier is preferably stored in field 6250 of the 
carrier database 6200. Finally, the carrier database 6200 preferably stores an indication 
in field 6255 of the percentage of CPOs which have been offered to each carrier which 
have actually been accepted by each respective carrier. In this manner, the CPO 
management system 5800 can offer a particular CPO to carriers in a sequence that is 

20 ranked in accordance with the CPO acceptance rate. In alternate embodiments, the 
carrier database 6200 can incorporate fields to facilitate the processing of CPOs in 
accordance with sequences based on (i) priorities negotiated by each carrier, or (ii) the 
highest commission rates paid by the carriers to the CPO management system 5800. 

Figure 63 illustrates an exemplary rate database 6300 that preferably 

25 stores published rate information for each carrier identified in the carrier database 6200. 
The rate database 6300 maintains a plurality of records, such as records 6305-6325, 
each associated with a different carrier. For each carrier identified in field 6340, the 
rate database 6300 preferably includes the corresponding domestic rate and international 
rate in fields 6345 and 6350, respectively. 

30 Figure 64 illustrates an exemplary CPO database 6400 which preferably 

contains a record of each CPO being processed by the CPO management system 5800, 
including the terms of the CPO and the associated status. The CPO database 6400 
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maintains a plurality of records, such as records 6405-6425, each associated with a 
different CPO being processed by the system 5800. For each CPO identified by CPO 
number in field 6440, the CPO database 6400 includes the date the CPO was received in 
field 6445, an identification (ED) number for the customer associated with the CPO in 
5 field 6450 and an indication of the telephone number to be called in field 6455. The 
parameters of the calling party's CPO are stored in field 6460 of the CPO database 
6400. The CPO database 6400 preferably stores the price the calling party is willing to 
pay for the call in field 6470. Field 6465 indicates the accepting carrier, once accepted 
and field 6475 records the current status of the respective CPO, such as pending, 
10 accepted, rejected or expired. 

PROCESSES 

As discussed above, the CPO management central server 6000 preferably 
executes a CPO management process 6500, shown in Figures 65a and 65b, to receive 
each CPO from a calling party 5810, provide the CPO to each appropriate interexchange 

15 carrier 5820 and thereafter determine if the terms of the offer have been accepted by any 
interexchange carrier 5820. As illustrated in Figure 8a, the CPO management process 
6500 begins the processes embodying the principles of the present invention during step 
6505, upon receipt of a call from a calling party 5810, for example, via a private branch 
exchange (PBX) switch of the CPO management system 5800. 

20 Thereafter, during step 6510, the CPO management process 6500 will 

extract the automatic number identification (AN1) number associated with the incoming 
call. A new record is then created in the customer database 6100 during step 6515 using 
the extracted ANI number as the customer identifier recorded in field 6160. Thereafter, 
the IVRU process 6600, discussed below in conjunction with Figures 66a and 66b, or 

25 another customer interface process, is preferably executed during step 6525 to receive 
the parameters of the CPO from the calling party 5810, including the telephone number 
of the called party 5830, the maximum price, the manner in which the CPO will be 
bound and any time limitations and other applicable restrictions. The received 
parameters of the CPO are then stored in the CPO database 6400 during step 6530, 

30 indexed by the customer identifier (ANI) and then provided to the appropriate carriers 
during step 6535 (Figure 65b). It is noted that the CPO management system 5800 can 
filter the CPOs provided to each carrier, for example, by only providing the CPO to 
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carriers who can route a call between the calling party 5810 and the desired called party 
5830 or only providing the CPOs to carriers designated by the calling party 58 10. It is 
further noted that the CPO management process 6500 preferably evaluates the CPO 
against the CPO rules provided by any agency-based carriers during step 6530 as well. 

A response to the CPO is preferably received from each carrier during 
step 6540. A test is then performed during step 6545 to determine if the terms of the 
CPO have been accepted by a carrier. If it is determined during step 6545 that the terms 
of the CPO have not been accepted by a carrier, then the calling party 58 10 is preferably 
notified during step 6550 that the CPO has been rejected. The status of the CPO in the 
CPO database 6400 is then changed to "rejected" during step 6555, before program 
control terminates during step 6560. 

If, however, it is determined during step 6545 that the terms of the CPO 
have been accepted by a carrier, then the full customer record from the CPO database 
6400 is preferably provided to the accepting carrier during step 6570 for the carrier to 
complete the call in accordance with the terms specified by the CPO. It is noted that the 
calling party 5810 may be billed for the call by the CPO management system 5800 or 
the local switch operator 5850 on behalf of the accepting interexchange carrier 5820, or 
directly by the accepting interexchange carrier 5820, in a conventional manner. The 
local switch operator 5850 typically receives a percentage of the total cost to complete 
the call. Finally, the status of the CPO in the CPO database 6400 is then changed to 
"accepted" during step 6575, before program control terminates during step 6580. 

As indicated above, the CPO management process 6500 preferably 
executes the IVRU process 6600, shown in Figures 66a and 66b, during step 6525 to 
receive the parameters of the CPO from the calling party 5810, including the telephone 
number of the called party 5830, the maximum price, and any time limitations and other 
applicable restrictions. As shown in Figure 66a, the IVRU process 6600 begins the 
processes embodying the principles of the present invention during step 6610 by 
prompting the calling party 5810 for the telephone number of the called party 5830. 
Thereafter, the interactive voice response unit (IVRU) captures the response of the 
calling party 5810 during step 6620 and provides the number to be called to the CPU 
6005. 
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The IVRU then prompts the calling party 5810 for the price the calling 
party 5810 wishes to pay for the call and the manner in which the CPO will be bound, 
such as a charge to a credit card account, during step 6630, and captures the response 
during step 6640 providing the maximum price for the call to the CPU 6005. 

5 Thereafter, the IVRU prompts the calling party 5810 for any other restrictions or 
specifications associated with the CPO during step 6650, including, for example, a time 
limit for the call, one or more desired carriers, if any, and a time limit for how long the 
CPO should be pending. The IVRU then captures the response of the calling party 5810 
during step 6660 and provides the additional restrictions or specifications to the CPU 

10 6005. Finally, the IVRU process 6600 instructs the calling party 5810 to hang up and 
wait for a response during step 6670 (Figure 66b), before program control terminates 
during step 6680. 

In this manner, the restrictions of the CPO are received by the CPO 
management system 5800 and then provided to each appropriate interexchange carrier 

15 5820. If accepted, the interexchange carrier 5820 will complete the call between the 
calling party 5810 and the desired called party 5830, in accordance with the terms of the 
CPO, and the calling party 5810 is obligated to pay the accepting interexchange carrier 
5820 for the cost of the call. 

In the embodiment shown in Figure 58 A, a calling party 58 10 desiring to 

20 place a call to a called party 5830 picks up the telephone set 5900 and dials a telephone 
number associated with the CPO management system 5800. The call is preferably 
received by a PBX switch or a related call processor. The telephone number of the 
calling party 5810 is then extracted from the call information, and used to access or 
create a record in the customer database 6100. The calling party 5810 is then connected 

25 to either an IVRU or a live operator to submit the terms of the calling party* s CPO, such 
as the number to be called and the maximum cost. The caller then is preferably 
instructed to hang up and wait for a response. 

Once the CPO is received and processed by the CPO management 
system 5800, it is then provided to a plurality of carriers. Each carrier 5820-5824 then 

30 determines whether to accept or reject the CPO, for example, based on one or more 
rules based on network capacity balancing. If the CPO is accepted, the CPO 
management system 5800 or the accepting carrier 5820 notifies the buyer and places the 
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call over the network of the accepting carrier. If there is a time limit or other 
restrictions associated with the call, the calling party 5810 is preferably notified at the 
time the call is initially established. The calling party 5810 may be billed for the call, 
for example, by the CPO management system 5800. the accepting carrier 5820. or by 
the local telephone company operating the local switch 5850. In this manner, the call 
may be individually charged to a general purpose account, such as a credit card, or may 
be paid for by means of the calling party's conventional telephone bill. 

Similarly, in the embodiment shown in Figure 58B. a calling party 5810 
desiring to submit a CPO for telephone service for a predefined period of time, may 
contact the CPO management system 5800 using a subscriber terminal 5815. The CPO 
can specify, for example, the rate which the subscriber is willing to pay for the 
telephone service and the length of the contractual obligation, as well as any flexibilities 
or restrictions that the calling party is willing to adhere to, in return for a discounted 
rate, such as calling during off-peak hours or a minimum spending obligation. 

Once the CPO is received and processed by the CPO management 
system 5800, the CPO is then provided to a plurality of carriers. Each carrier 5820- 
5824 then determines whether to accept or reject the CPO. If the CPO is accepted, the 
CPO management system 5800 or the accepting carrier 5820 notifies the buyer and 
switches the long distance provider for the calling party to the accepting carrier 5820, in 
an appropriate manner. 

CPO MANAGEMENT SYSTEM FOR EVENT TICKETS 
Another embodiment of the present invention will now be discussed with 
reference to Figures 67 through 73g. The embodiment shown in Figures 67 through 73 allows 
a buyer to present a guaranteed purchase offer for a ticket to a certain event, such as a hockey 
game, to a number of potential sellers. The sellers may review the offer, and accept the offer if 
the terms are agreeable. Thus, a buyer may quickly submit an offer to purchase tickets which 
are guaranteed to be delivered in a safe, convenient manner. 

With reference to Figures 67-72b, the system architecture of one embodiment of 
the apparatus and method of the present invention is illustrated. As shown in Figure 67. the 
apparatus of the present invention generally comprises a venue controller 7000, a central 
controller 6800. a credit card processor 6830 and a remote user terminal 6900. The remote user 
terminal 6900 is connected to the central controller 6800 through a network 6845. 
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Using the above components, the present embodiment of the invention provides 
a method and apparatus to allow a central controller to facilitate the purchase and sale of event 
tickets. Specifically, central controller 6800 receives and posts offers to purchase tickets for a 
particular event. Such offers are guaranteed, for example, using a line of credit on a credit card 
5 account. Central controller 6800 further makes each offer available to a plurality of potential 
sellers, and allows sellers to accept the offer and thereby form a legally binding contract. 

As shown in Figure 68, central controller 6800 includes central processing unit 
(CPU) 6805, random access memory (RAM) 6815, read only memory (ROM) 6820. clock 
6835, input/output ("I/O") port 6855, and data storage device 6850. The data storage device 
10 6850 is a memory device containing an event table 7 1 00, a venue table 7 1 20, a customer table 
7130, an offer table 7150, and a transaction table 7180, discussed in greater detail with 
reference to Figures 71a through 71e. respectively. 

Figure 7 1 a illustrates an exemplary event table 7 1 00 that preferably stores 
information on events for which tickets may be resold using the system of Figure 67, including 
15 location and scheduling information. Event table 7 100 maintains a plurality of records, such as 
record 71 14, each associated with a different event. For each event identifier listed in event ID 
field 7102, event table 7100 includes an event type code stored in field 7104 and an event 
description stored in field 7106. The event type code stored in field 7104 represents the format 
of the event, for instance, a National Hockey League game is denoted as "NHL." The event 
20 description stored in field 7106 describes the specific event. 

Event table 7100 also preferably includes a venue ID stored in field 7106. The 
venue ID stored in field 7106 may be utilized, for example, to index venue table 7120, more 
fully described with reference to Figure 71b. As shown in Figure 71a. each record stored in 
event table 7100 further includes a date stored in field 71 10 and a time stored in field 71 12. 
25 The date and time of fields 7110 and 7112, respectively, represent the starting time of the event 
associated with the record. The information stored in this table may be supplied to the central 
controller 6800 from any number of sources, including promoters, venues and potential buyers 
and sellers. 

Figure 71b illustrates an exemplary venue table 7120. Each record of venue 
30 table 7120, such as record 7128, preferably stores data associated with and describing a venue. 
Venue table 7120 is preferably indexed by field 7122 which stores a unique venue identifier. 
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Venue table 7120 further stores a theater, auditorium or stadium name in field 7124 and an 
address in field 7126. 

Figure 71c illustrates an exemplary customer table 7130 which preferably stores 
information on each customer registered with the electronic ticket sales system. Customer 
database 7130 maintains a plurality of records, such as records 7146 and 7148, each associated 
with a different customer. Customers registered in customer table 7130 may buy tickets, sell 
tickets or both buy and sell tickets. Customer table 7 1 30 stores a unique customer identifier for 
each customer in field 7132 and name and address information in fields 7134 and 7136. 
Preferably, the data maintained in customer table 7130 is provided by the customer during a 
registration process, at which time the customer is assigned a unique customer identifier. 

Customer table 7130 further stores customer credit card data. The customer's 
credit card number is stored in field 7138. The expiration date of the customer s credit card is 
stored in field 7140, and the name of the cardholder as it appears on the credit card is stored in 
field 7142. 

Figure 7 1 d illustrates an exemplary offer table 7 1 50 that preferably stores 
information relating to offers posted using the ticket sales system of the present embodiment. 
Offer table 7150 maintains a plurality of records, such as records 7170 and 7172, each 
associated with an offer to buy or sell tickets. Each record of offer table 7 1 50 includes a unique 
offer identifier stored in field 7151 that is assigned by central controller 6800 when the offer is 
posted. Each record of offer table 7150 includes fields for identifying the customer making the 
offer, conditions of the offer, the customer accepting the offer, and administrative information 
related to the offer. 

The customer identifier of the customer extending the offer is stored in field 
7152. Information relating to the customer extending the offer may be easily obtained using the 
customer identifier of field 7152 as an index into customer table 7130. Each record in offer 
table 7150 further stores an event identifier in field 7153. The event identifier indicates the 
event to which the offered ticket(s) relate. Information regarding the event may be easily 
obtained using the event identifier of field 7153 as an index into event table 7100. 

Each record of offer table 7150 further includes fields 7154 and 7155 that store 
the date the offer was made and the last day on which the offer may be accepted, respectively. 
Data indicating an offer type and offer status are also stored in each record of offer table 7150 
in fields 7156 and 7157. Field 7156 stores a code indicating whether the offer is an offer to buy 
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or an offer to sell one or more tickets. Field 7 1 57 stores a code indicating the status of the 
offer. Offer status possibilities include: pending, active, expired and fulfilled. 

Field 7158 of each record in the offer table stores the number of seats to which 
the offer applies. Data identifying the location of seats related to the offer populate fields 7 159- 
7164. In the event an offer requires a range of seat locations, data stored in fields 7159-7161 
are used to identify the first seat in a range, and data stored in fields 7 162-7 1 64 are used to 
identify the last seat in a range. Field 7 1 65 stores the price per seat. 

In addition, each record of offer table 7150 includes administrative data in fields 
7166-7169. Data stored in field 7166 stores an amount of credit authorized to support the offer. 
Once an offer has been accepted, field 7167 stores a transaction identifier that may be used as 
an index into transaction table 7180, discussed more completely with reference to Figure 71c. 
Each record of offer table 7150 optionally stores a pointer to a related, or linked, offer record. 
The pointer is stored in field 7168 and represents the offer identifier of the next related record 
in offer table 7 150. Finally, field 7169 of each record of offer table 7150 stores one or more 
serial numbers of the original tickets that a seller would like to sell. 

Once an offer is accepted, central controller 6800 adds a transaction record to 
transaction table 7 1 80. Figure 7 1 e illustrates an exemplary transaction table 7 1 80 that 
preferably stores information relating to each accepted offer. Each accepted offer is assigned a 
unique transaction identifier that is stored in field 7181 of transaction table 7180 and field 7167 
of offer table 7150. An offer identifier of an associated record in offer table 7150 is stored in 
field 7 182. This offer identifier may be used as an index into offer table 7 1 50 to retrieve 
information regarding the offer associated with a transaction record. 

Each record of transaction table 7180 preferably further includes field 7183 
which stores the date the associated offer was accepted and field 7184 which stores the total 
value of the transaction. Field 7185 stores the amount charged to the buyer s credit card; field 

7 1 86 stores the amount of the seller's credit line reserved to support the acceptance; and field 

7187 stores the fee charged for processing the transaction. Each record of transaction table 
71 80 also stores a date in field 71 88 indicating the date the ticket(s) are received by the 
operator of controller 6800. 

The customer identifier of the seller is stored in field 7189, and data identifying 
the ticket(s) is stored in fields 7190 and 7194. Field 7190 stores the original ticket number(s), 
and field 7194 stores new ticket number(s). The new ticket numbers are assigned to distinguish 
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original tickets from resold tickets and promote efficient resolution of potential conflicts 
between ticket holders. 

Optionally, central controller 6800 may include a contract detail table (not 
shown) containing form contract provisions which the central processor 6800 retrieves and 
5 transmits to users at various times. For example, the contract table may include a contract 
provision that is transmitted to a buyer and incorporated into the guaranteed purchase offer. 
The contract table may also include a contract provision which is transmitted to a seller prior to 
requesting an acknowledgment of his intent to bind a buyer's offer and create a legally binding 
contract. These form provisions effectively fill the gaps between conditions specified by the 

10 buyer, specifying the generic contract details common to most contracts of this nature. 

Referring now to Figure 69, remote user terminal 6900 wilt now be described in 
greater detail. Remote user terminal 6900 can be a personal computer, screenphone. stand alone 
kiosk, or any other device through which a customer can access the central controller 6800. 
Remote user terminal 6900 generally includes a central processing unit ("CPU") 6905 that 

15 controls the operation of remote user terminal 6900. CPU 6905 is electronically connected to a 
random access memory ("RAM") 6915, a read only memory ("ROM") 6920, an input/output 
port 6925 ? a clock 6935, a communication port 6940 and a data storage device 6960. CPU 6905 
receives inputs from a remote user with the input/output port 6925 and an input device 6945, 
such as a keyboard. CPU 6905 transmits outputs to a remote user via the input/output port 6925 

20 and a video monitor 6930. Further, the communication port 6940 provides the communication 
path to network 6845. Finally, the data storage device 6960 is a memory device containing 
central controller interface software 6965. 

Referring now to figure 70, venue controller 7000 will now be described in 
greater detail. Venue controller 7000 generally includes a central processing unit ("CPU") 

25 7010 that controls the operation of venue controller 7000. The CPU 7010 is electronically 
connected to a random access memory ("RAM") 7020, a read only memory ("ROM") 7030, a 
clock 7040, a communication port 7050 that provides a communication path to central 
controller 6800, and a data storage device 7060. Data storage device 7060 is a persistent 
memory device containing a ticket table 7210 and a replacement ticket table 7230. Venue 

30 controller 7000 further includes input device 7080 for receiving input data and output device 
7070 for presenting or displaying information to an operator. 
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Figure 72a illustrates an exemplary ticket table 72 10 that preferably stores 
information about tickets issued for various seats at a particular venue. Each ticket has a 
specific ticket number assigned to it by venue controller 7000 prior to issuance. Each record of 
ticket table 72 10 preferably includes field 72 1 1 that identifies the event for which the ticket is 
valid, field 7212 that identifies the number assigned to each ticket issued for an event, and 
fields 7214-7220 that represent the location of the seat in the auditorium (i.e. the section, row 
and seat, respectively). Ticket table 7210 could also contain fields representing other 
information specific to a venue, an event, or a scat. 

Figure 72b illustrates an exemplary replacement ticket table 7230 that preferably 
stores data relating to original ticket numbers that have been voided and assigned replacement 
ticket numbers. Replacement ticket table 7230 stores the ticket numbers that have been resold 
by the central controller 6800 in field 7232 and stores the replacement ticket numbers in field 
7242. Each record of ticket table 7230 further includes a field 7231 that stores an event 
identifier and a field 7240 that stores a buyer identifier. 

It will be recognized by one of ordinary skill that the present invention could be 
constructed and operated without the illustrated distributed processing architecture. If venues 
and ticket distributors so desired, central controller 6800 could incorporate all or part of the 
database of venue controller 7000 and perform all or part of the processing steps performed by 
venue controller 7000 in the present embodiment. In such an alternate embodiment, data 
processing and data storage could be centralized, and venues could access the data as 
appropriate using conventional remote terminals or work stations. 

In one embodiment of the present invention, communications between potential 
buyers and sellers take place via an electronic or digital network, such as the Internet, with 
central controller 6800 hosting an Internet web site that users can access or "log on" to by 
means of a personal computer. It is important to note that users can access the central controller 
via other communications links such as a conventional telephone line linked to a voice response 
unit ("VRIT). 

To use the ticket reselling service, a user who is a potential buyer logs on to 
central controller 6800 through network 6845, creates and submits a guaranteed purchase offer, 
and disconnects from the network 6845. In one embodiment, a guaranteed purchase offer is a 
legally binding offer to purchase tickets that is backed by a pre-authorized credit card 
transaction. Upon receiving the offer, central controller 6800 contacts the buyer s credit card 
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issuer to ensure that the buyer has a valid credit card account and/or sufficient credit to pay for 
the requested tickets. The guaranteed purchase offer is then made available to potential sellers 
by posting the offer using the web site linked to central controller 6800. Periodic maintenance 
is performed by central controller 6800 to ensure that "active" offers have not expired. A 
potential seller can use the system of the present invention to browse offers and submit an 
electronic acceptance of a desirable offer. The acceptance by the potential seller is transmitted 
electronically to central controller 6800. Central controller 6800 processes the acceptance and 
contacts the seller's credit card issuer to ensure that there is sufficient credit to cover a potential 
penalty for non-performance. This reservation of the seller's credit is intended to promote trust 
between the parties and, thereby, protect the transaction. After verifying available credit, both 
parties are notified of the binding transaction, and the tickets are electronically voided and 
assigned a replacement ticket number. The seller is then required to surrender the voided 
tickets. This may be accomplished by returning them to the venue, or the seller may mail the 
tickets to the operator of central controller 6800. Upon receiving the surrendered tickets, the 
operator of central controller 6800 directs payment to be transferred to the user selline the 
tickets. 

With reference to Figure 73a, a process by which a user logs on and begins using 
the system will now be described. As shown in step 7300. a user operating a remote terminal 
6900 establishes a connection with the central controller 6800 through network 6S45. The user 
may be either a potential buyer wishing to place a guaranteed purchase offer for tickets, or a 
potential seller wishing to review offers for tickets. 

At step 7302. centra] controller 6800 requests a customer ID from the user. At 
step 7304. central controller 6800 determines how to proceed based on whether or not the user 
already has a customer ID. If the user is registered with this service, and remembers his 
customer ED, he transmits his customer ID to central controller 6800 at step 7312. and the 
process continues with step 7314. 

If, on the other hand, the user is not registered with the service, or does not 
remember his customer ID, he must submit a negative response at step 7304 and present 
relevant customer information to central controller 6800, as shown by step 7306. At step 7308. 
central controller 6800 creates a record of the customer based on the received customer 
information. This information, including name, address, credit card and number, expiration 
date, and name as it appears on the credit card, is stored in customer table 7130. At step 7310, 
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central controller 6800 compares the information provided by the user with information already 
stored in customer table 7 1 30. If a match is found, central controller 6800 retrieves the 
customer ID from field 7 1 32 of customer table 7 1 30, and transmits the customer ID number to 
the user. This service is provided for users who have given information previously, but do not 
remember their customer ID number. If no match is found, the central controller 6800 assigns a 
new customer ID to the user, stores it in field 7 1 32 of customer table 7 1 30, and transmits it to 
the user. 

At step 7314 the user indicates whether he would like to submit a guaranteed 
purchase offer, or review offers from potential buyers. The process steps relating to submitting 
offers are described more fully with reference to figures 73b-73c. The process steps relating to 
reviewing offers are described more fully with reference to figures 73d-73g. In an alternative 
embodiment, the user could also elect to advertise the availability of tickets for a certain event 
to potential buyers. Furthermore, a user could elect to review such advertisements, to get a 
better understanding of what a fair price might be, prior to submitting an offer. 

Figures 73b and 73c illustrate the process steps executed following the user s 
choice at step 7314 to submit a guaranteed purchase offer. At step 7316, the central controller 
transmits general venue and event information to user terminal 6900 for display to the user. 
For instance, in one embodiment, central controller 6800 may provide a number of options to 
the user in order to pinpoint the specific event that the user would like to attend. The user could 
directly request a particular event, or proceed through a group of narrowing choices to 
ultimately find the right event. A user, for example, may be asked to identify any of the fields 
from event table 7 100. Depending on the amount of information provided, the choice of events 
will be narrowed accordingly. For instance, if the user provides only the event type (e.g. 
"NHL"), central controller 6800 scans the event table 7100 and provides all matches found in 
the event type field 7104. This may be a long list of events, however, central controller 6800 
may prompt the user for more information to narrow the list. The user may then select from the 
narrow list to find the event for which he is looking. For example, the user may specify only 
Saturday matinee performances of a particular Broadway production in order to narrow the list- 
Central controller 6800 then provides the user with the correct event information, including the 
event ID from field 7102 of the event table 7100. The user includes this event ID as part of 
their guaranteed purchase offer so that it may be tracked by central controller in the offer table 
7150. 
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Next, at step 7318, the user selects the desired event based on the event ID 
number. At step 7320, central controller 6800 requests certain information from the user 
pertaining to the offer, such as 

( 1 ) the number of tickets desired: 

(2) the price for each ticket: 

(3) the location desired for each ticket: and 

(4) optionally, a date through which the offer is valid. 

The user indicates the number of tickets he would like and the price he is willing 
to spend, based on the particular location of the tickets. The user may choose the exact 
location of seats that correspond to the price he is willing to pay using a graphical 
representation of the venue. For instance, based on the venue ID number (stored in field 7122 
of venue table 7120), central controller 6800 retrieves from memory and provides to the user at 
remote user terminal 6900 a graphical representation of seating at that particular venue. In one 
embodiment, central controller 6800 first provides a broad general outline of the entire venue 
(e.g., display by sections). The user can then click on a particular area to narrow his search for 
exact seats. With each successive selection click, the display screen at user terminal 6900 
narrows the scope of displayed seating until the user finds the seats he desires. The user can 
then select the group of seats which corresponds to the purchase offer. Central controller 6800 
stores the selected seats in fields 7159-7164 of the offer table 7150. If the user prefers to select 
one section or multiple sections instead of specific seats, he can enter a range of selections. 
Central controller 6800 then stores this broader selection by only using the section fields 7159 
and 7162. and leaving the other four fields empty. 

Further, the user may provide a close date to denote a date on which the offer 
expires. As previously discussed, central controller 6800 periodically reviews this close date, 
and changes the status of the offer to "expired" in field 7157 of the offer table 7150 once the 
date has passed. 

At step 7322, central controller 6800 receives the offer information transmitted 
by the user, and as shown in step 7324, central controller 6800 creates a record of the offer in 
offer table 7150. At step 7328, the user is asked if he would like to make additional offers. At 
this point, if the user would like to make an offer for a separate event, he may go through the 
same process discussed in steps 7316-7324. However, if the user would like to make a related, 
or linked offer to the offer previously provided, they may do so as follows. First, in one 
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embodiment they provide the same event ID as at step 7318. Next, after submitting the same 
general information previously discussed, the user indicates that this offer is linked. The 
central controller then assigns the offer ID number created for the initial offer as the link ID 
number for the related offer, and stores in the link ID field 7168 of the offer table 7150. 

5 A user might provide a linked offer based on the type of seat desired. For 

instance, the user might select a number of the "high quality" seats in a particular venue, and 
offer a higher purchase price. The linked offer would include "lower quality" seats for a 
particular venue, perhaps at a lower purchase price. Thus, based on the link ID. potential 
sellers will consider both offers together during their review. 

10 Also, the user may link offers for two separate events as opposed to the same 

one. For example, instead of linking offers based on seat selection and price, the user may 
prefer to attend one of two events in the local area, but not both. Thus, he could link these 
offers so that potential sellers would be made aware that the offers were conditioned against an 
"either/or" proposition. 

15 The central. controller 6800 assigns an offer ID number to each offer in the offer 

ID field 7151, and assigns this number as the link ID number for linked offers in link ID field 
7 168. Also, the offer date field 71 54 is populated with a timestamp (e.g., date and time) 
indicating when the offer was posted. Next, central controller 6800 assigns the value "pending" 
to the status field 7157. This value will change to "active" upon receipt of authorization from 

20 the user s credit card issuer. Further, central controller 6800 calculates the authorized amount, 
and stores it in authorized amount field 7166. The authorized amount field represents the 
amount of the user's credit which is reserved to "back up" the offer and is usually equal to the 
total transaction amount. By reserving a portion of the user's credit, the ticket seller and ticket 
service can be guaranteed that they will receive payment if the offer is accepted. In case of 

25 linked offers to buy, the authorized amount is the highest transaction amount of the linked 

offers. When a linked offer is accepted, the system automatically considers all related offers to 
be withdrawn. Finally, central controller 6800 stores all the information provided by the user, 
including the seat location based on the graphical representation of the venue, in the respective 
fields of the offer table 7 1 50. 

30 At step 7330, the central controller 6800 extracts legal contract language from 

the contract detail table (not shown) and transmits to the user at user terminal 6900. This 
language describes the legal implications of offering the guaranteed purchase offer, and the 
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process is similar to reviewing terms before signing a written contract. If the user elects not to 
abide by these terms, he may cancel the offer. However, if the user does elect to abide by the 
terms, the user transmits a positive acknowledgment to central controller 6800. and is legally 
bound to the terms of the guaranteed purchase offer. 

In Figure 73c, central controller 6800 then contacts the user s credit card issuer 
at step 7332 to receive authorization for the offer. First, central controller 6800 collects the 
user name, address, credit card type, credit card number, and expiration date from customer 
table 7130, based on the customer ID from the offer table 7 150. This information along with 
the authorization amount from field 7166 of the offer table 7150 is transmitted to the credit card 
issuer through credit card processor 6830. 

At step 7334, the central controller 6800 receives either an authorization or 
rejection from the credit card issuer through credit card processor 6830. The credit card issuer 
may reject the request for any number of reasons, including an expired card, overextended 
credit limit, or delinquency in payments. Upon rejection, at step 7336 central controller 6800 
notifies the user at user terminal 6900 of this rejection and requests separate credit card 
information. Alternatively, the user may transmit information corresponding to a separate 
credit card, which supplements or replaces his present information in the customer table 7130. 
If alternative credit card information is provided, step 7332 is repeated in order to receive 
authorization for the charge. Upon receiving authorization from the credit card issuer through 
the credit card processor 6830, central controller 6800 updates offer table 7120. includine 
changing status field 7157 to "active" to confirm the posted offer. 

Figures 73d-73g illustrate the processing steps executed based on the users 
choice at step 73 14 to review offers from potential buyers. At step 7340. central controller 
6800 transmits general venue and event information to user terminal 6900 for display to the 
user. As discussed earlier at step 73 1 6, central controller 6800 may provide a number of 
options to the user to identify the exact event the user wishes to review. Ultimately, central 
controller 6800 provides the user with the event ID from field 7102 of the event table 7100. At 
step 7342, the user supplies the event ID to central controller 6800 so it may identify associated 
offers in offer table 7 1 50. 

At step 7344, central controller 6800 identifies offer records associated with the 
selected event ID and having an "active" status.. Central controller 6800 transmits this data to 
user terminal 6900 for display to the user. The user may review all offers for the specific event 
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10 



together, or one at a time. In one embodiment, the user may review each individual offer 
through a graphic display of the venue, to pinpoint exactly where the buyer is requesting seats. 
In some cases, the offer may be for seats anywhere in the entire arena. In others, the offer may 
only be for a specific range of sections, rows or seats. In one embodiment, the user may be able 
to enter their exact ticket information to confirm whether it meets the requirements of the offer. 

As previously discussed, linked offers will be appropriately identified upon 
presentation to the user. In this case, central controller 6800 allows associated linked offers to 
be reviewed simultaneously, so that the user can compare the conditional offers submitted from 
a single buyer. 

Next, at step 7346, central controller 6800 receives either a request to accept a 
particular offer, or a request to review offers lor other events. In the latter case, steps 7340. 
7342 and 7346 will be repeated. It should be noted that the user may exit the system at any 
time prior to accepting an offer. 

After.the user transmits a request to accept a particular offer, at step 7348 the 
15 user transmits the original ticket number and seat location < i.e. section, row and seat) to central 
controller 6800. Upon receiving this information from the user, central controller 6800 at step 
7350 transmits the original ticket number and seat location to the venue controller 7000 for 
verification of the ticket's validity. 

Referring now to Figure 73e. at step 7352 venue controller 7000 retrieves a 
20 record from ticket table 7210 matching the ticket number transmitted by central controller 6800 
in step 7350. Venue controller 7000 verifies that the transmitted ticket number matches the 
transmitted seat location at steps 7354 and 7356. If the transmitted ticket and seat location do 
not match, at step 7358, venue controller 7000 transmits an invalid combination message to 
central controller 6800. Central controller 6800 then transmits a message to user terminal 6900 
25 indicating that the ticket number and seat location are an invalid combination at step 7360. 
Upon receiving the invalid combination message at user terminal 6900, the user can resubmit 
the ticket and seat location to central controller 6800 at step 7370. The process then loops back 
to step 7350. If the ticket number and seat location combination is valid, the process continues 
with step 7372. 

30 At step 7372 of Figure 73f, central controller 6800 transmits to user terminal 

6900 legal contract language which is displayed to the user selling his ticket. As previously 
indicated, this contract language may be stored in a contract detail table (not shown). This 
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language describes the legal implications of accepting the guaranteed purchase offer, and the 
process is similar to reviewing terms before signing a written contract. If the user selling his 
ticket elects not to abide by these terms, the user may cancel his acceptance. However, if the 
user elects to abide by the terms, the user transmits a positive acknowledgment to central 
controller 6800, and is legally bound to the acceptance. 

Central controller 6800 then contacts the user s credit card issuer at step 7376 to 
receive authorization for the acceptance. Central controller 6800 requests authorization from 
the credit card issuer to reserve a portion of the user's credit based on the offer information and 
credit information collected from the user at step 7306 and stored in customer table 7130. This 
credit reservation is a fraud deterrent and may be used as a penalty in the event the seller fails 
to deliver the tickets. Such a penally creates buyer confidence and provides assurance to a user 
buying the ticket that the user selling the ticket will, in fact, relinquish the tickets. The penalty 
could be paid to the user buying the ticket if the user selling the ticket attempts to repudiate the 
agreement. This penalty may be determined in a number of ways including imposing a flat 
penalty on the user selling the ticket or imposing a penalty equal to the entire amount offered 
by the user buying the ticket. 

At step 7374. central controller 6800 collects information from the user selling 
the ticket. The information may include the user name, address, credit card number and 
expiration date from customer table 7 130, based on the customer ID retrieved from the offer 
table 7150. This information, along with the authorization amount from field 7166 of the offer 
table 7150. is transmitted to the credit card issuer through credit card processor 6830. 

At step 7376. central controller 6800 receives cither an authorization or rejection 
from the credit card issuer through credit card processor 6830. The credit card issuer may 
reject the request for any number of reasons, including an expired card, overextended credit 
limit, or delinquency in payments. Upon rejection, at step 7328 central controller 6800 notifies 
the user at user terminal 6900 of the rejection and requests alternate credit card information. 
The user may attempt to transmit the same credit information as provided earlier, because the 
user may have mistakenly transmitted incorrect information earlier. Alternatively, the user may 
transmit information corresponding to an alternate credit card, which will supplement or 
replace the credit card information in customer table 7130. Further, the user could cancel the 
transaction altogether. If alternative credit card information is provided, step 7374 is repeated 
in order to receive authorization for the charge. 



133 



WO 98/10361 



PCI7US97/15492 



If central controller 6800 receives authorization from the credit card issuer 
through credit card processor 6830. the process continues with step 7380 wherein central 
controller 6800 generates and assigns a transaction ID to the sale. This transaction ID is stored 
in field 7167 of the offer table 7150. Further, central controller 6800 creates a new record in 
transaction table 7180, indexed by the assigned transaction ID. The assigned transaction ID is 
also stored in field 7181 of transaction table 7180. The original ticket number 7190 field of 
transaction table 7180 is populated with the appropriate ticket numberfs) from the user selling 
the ticket. Further, central controller 6800 timestamps the acceptance using date field 7183 
indicating when the acceptance was posted. 

Once the guaranteed purchase offer has been accepted, central controller 6800 
uses the customer ID from field 7152 as an index into customer table 7130 to retrieve the name 
of the user buying the ticket. At step 7382. central controller 6800 transmits the name of user 
buying the ticket to the venue controller 7000. 

At step 7384, venue controller 7000 creates a new record in replacement ticket 
table 7230. The new record is populated with information indicating the buyer's name, the 
original ticket number, the section, row and seat of the ticket. As shown at step 7386, the new 
record is further populated with a replacement ticket number assigned by venue controller 
7000. The replacement ticket number is then transmitted to central controller 6800 

Once central controller 6800 has received the replacement ticket number 7242 
from venue controller 7000, central controller 6800 then updates the new ticket number field 
7 194 of transaction table 7 1 80 at step 7388. At step 7390. central controller 6800 determines 
the payment due and charges the credit card, of the user buying the ticket, the price of the ticket 
plus a processing fee 7187. Central controller 6800 also updates field 7185 of the transaction 
table 7180 with the amount charged. Finally, central controller 6800 updates field 7 189 with 
the seller ID of the user accepting the offer, and central controller 6800 updates field 7186 with 
the seller amount authorized in the event that the seller tries to use his sold ticket. Field 7 1 84 
is updated based on buyer amount charged 7185 less the processing fee 7187. Although fees of 
the present embodiment are illustrated as being stored in a table, such fees could easily be 
calculated instead of being retrieved from a table. 

At step 7392, central controller 6800 transmits a message to user terminal 6900 
to notify the user selling the ticket that it will credit his credit card account with the sale amount 
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of the ticket as soon as central controller 6800 receives verification that ihe original tickets have 
been surrendered. 

At step 7394 the central controller transmits replacement ticket number 7292 
and a message to the user buying the ticket indicating that his guaranteed offer has been 
5 accepted. The user buying the ticket may then print the replacement ticket number, take it to 
the venue and use it to gain access to the desired event, at step 7396. The cancellation of the 
original number and issuance of a replacement ticket, number tied to the purchasing .user's ..name 
is done in order to prevent fraud by either the ticket seller and/or the purchaser. 

For instance, if a seller arrives at a venue with a ticket, and a purchaser also 

10 arrives to the same venue with a replacement ticket for the same seat, the venue controller can 
be accessed to determine which ticket is valid. The replacement ticket always supersedes the 
original ticket, provided it is registered in the replacement ticket table 7230 of the venue 
controller 7000. If such fraud is attempted by the seller and detected by central controller 6800. 
the central controller can charge the seller's credit card account the seller amount authorized in 

15 field 856 of transaction table 7 1 80. 

As another example, if two people arrive at the venue with the same replacement 
ticket, the venue controller can be accessed to determine the rightful owner, based on the 
contents of the new buyer name field 7240, of replacement ticket table 7230. These measures 
taken against fraud will assure customers that there will be no problems in using central 

20 controller 6800 to buy and sell tickets. 

Finally, at step 7398. central controller 6800 receives verification that the 
original ticket has been received from the seller, and credits the credit card account of the user 
selling the ticket with the transaction amount 7184. Central controller further updates the date 
tickets received field 7188 accordingly. Surrender of the ticket is preferably accomplished by 

25 delivery of the ticket to a will call window of the venue, however other surrender arrangements 
are possible, such as through the postal service or Federal Express. Once the ticket has been 
surrendered and the transaction is complete, central controller 6800 updates status field 7157 of 
the offer table 7 1 50 to "completed" for tracking purposes. Upon receipt of the surrendered 
tickets, central controller 6800 credits the account of the user selling the tickets. 

30 Although the preferred method of surrendering the original tickets is using the 

mail or other delivery mechanism, numerous alternate embodiments are possible. Using one 
alternate embodiment, ticket redemption could be constructively accomplished at the time an 
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offer to buy is irrevocably accepted. The alternate embodiment employs event tickets that can 
be physically altered to render them invalid or void. Each ticket includes a unique ticket 
. number that is prc-printed on the face of the ticket, but obscured from view by a scratch-off 
covering, such as an opaque latex coating. The ticket number is unknown to the ticket holder 

5 unless the scratch-off covering is removed. 

At the time of acceptance, the seller possessing the tickets is instructed to 
remove the covering over the ticket number on each ticket to be sold. The ticket number is 
provided to central controller 6800 to verify that the ticket seller is, in fact, in possession of 
valid tickets. The ticket number provided for each ticket involved in the transaction is then 

10 electronically voided and replacement ticket number is assigned as previously described. 

The act of revealing the ticket number not only serves to verify the ticket seller s 
possession of the tickets, but also eliminates the need for the seller to surrender the tickets 
because removal of the scratch-off covering voids the tickets. While this alternate embodiment 
requires additional structure with respect to the event tickets, it eliminates the need to reserve a 

15 portion of the seller's credit line as a penalty for failing to return the unused tickets. 

An illustrative example of the invention will now be described using the data 
populating various fields of the figures. Record 7172 of the offer table 7150 is a guaranteed 
offer to buy as indicated by type field 7156 that has been submitted by user 4000 as identified 
by customer ID field 7152. User 4000. as denoted by record 7 1 48 in the customer table 7 1 30 is 

20 Sue Black, residing at 101 Pink Ave in Norwalk, CT. The credit card number submitted to 
central controller 6800 is Discover card number 4444-4444-4444-4444 that expires 9/02 and 
was issued to Susan Black. 

In record 7172 of the offer table 7150, Sue Black has posted a guaranteed offer 
to buy two tickets to event ID E001 , as denoted by event ID field 7153, for $200.00 per ticket 

25 in the first row of the first section of the venue. As denoted by record 7 1 1 4 of event table 7 100, 
event E001 is an NHL game, specifically NJ Devils vs. New York Rangers, occurring on 5/6/97 
at 7:30 PM at "MSG" as denoted by venue ID field 7108. Record 7126 of venue table 7120 
identifies MSG as the Madison Square Garden venue in New York, NY. 

In addition to this guaranteed purchase offer, Sue Black has also posted a link 

30 offer as denoted by linked ID field 7 1 68. This linked offer has an ID code of 0333. Record 

7170 of offer table 7150 has the offer ID 0333, and is therefore the offer that is linked to record 
7172. Record 7170 is an offer by Sue Black to purchase four tickets to the NHL game NJ 
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Devils vs. New York Rangers having the same date and time as the offer request of record 
7172. In record 7170, Sue Black indicates that she will pay S250 each for four tickets in the 
first row of the first section of the venue. Because offer 7170 is linked to offer 7172, Sue Black 
has indicated that she would like one or the other of the two offers. 

Field 7 1 66 of offer table 7 1 50 indicates that $ 1 ,000 has been authorized by 
Discover for account 4444-4444-4444-4444 for both records 7170 and 7172, submitted by Sue 
Black. $1,000 is the maximum possible amount that Sue Black's offers could cost her if one of 
them is fulfilled. 

For record 7172, the transaction ID field 7167 has been populated with a 
transaction ID, indicating that a buyer has accepted Sue Black's guaranteed offer to buy. Status 
field 7157 of record 7172 registers that the offer has been fulfilled, and the status record 7170 is 
expired, since it was linked to record 7172 in a way indicating that if one was filled, the other 
should be disregarded. 

Record 7 1 95 of transaction tabic 7 1 80 describes the detail of transaction TR00 1 . 
which is the acceptance of Sue Black's guaranteed offer to buy by seller 2000. as indicated by 
seller ID field 7 189. 

Record 7170 of the customer table 7 130 indicates that customer having the ID 
number 2000, as indicated by customer ID field 7132, is Jill Janson. residing in 456 Red Drive, 
Atlanta GA, and having Master Card number 2222-2222-2222-2222 with expiration date 9/99 
registered with central controller 6800. 

Record 7195 indicates that Sue Black was charged $420 on 5/2/97 for her 
purchase of seats 003 and 004 of row 1 . seat 1 of the event tied to the record of her guaranteed 
purchase offer in offer table 7 1 50. Record 7 195 also indicates that Jill Janson has sold her 
original ticket numbers 6679 1 3 and 6679 1 4, stored in the original ticket number field 8 1 0, for 
section 001, row 001, and seat 003 and 004. The seller amount authorized field 7185 stores 
$400, the amount that central controller 6800 has been authorized by Mastercard to debit from 
account 2222-2222-2222-2222 in the event that Jill Janson does not honor her agreement to sell 
her tickets. All or a portion of this amount can be credited to Sue Black if there is a problem 
using her new ticket number for access to the venue event. 

The date tickets received field 7188 is blank for this record, indicating that 
central controller 6800 has not yet received verification that Jill Janson has surrendered her 
tickets. Once central controller 6800 has received verification that Jill Janson has surrendered 
» 
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her tickets. Jill Janson "s credit card account will be credited S380, the amount stored in 
transaction amount field 7 1 84. 

Central controller 6800 has issued replacement ticket numbers to Sue Black for 
both seats. These replacement ticket numbers are stored in field 7194. Preferably. Sue Black 
will print out these replacement ticket numbers and take them with her to the venue to gain 
access to the event. 

Records 7222 and 7224 of ticket table 7210 store information relating to the 
original tickets issued to Jill Janson. Records 7244 and 7246 of replacement ticket table 7230 
store the replacement ticket numbers issued by central controller 6800 to Sue Black, which 
replace the original ticket numbers given to Jill Janson. These records are stored by venue _ 
controller 7000 to be used in the event of fraud as previously described. 

It is important to note that in the embodiment described above, the notification 
of the parties, both buyer and seller is performed through contacting their respective remote 
user terminals. This notification can also be performed using conventional technology including 
but not limited to telephone, facsimile, e-mail and paging. 

In addition to the guaranteed offer and acceptance system of the present 
invention, the present embodiment is also well suited for other aspects of ticket resale. For 
example, the present embodiment can include a registration process for certain events or 
tickets. Such a process would enable a prospective ticket buyer to set up a ticket watch which 
could be implemented by central controller 6800. Central controller 6800 could periodically 
poll offers to determine if specific tickets are available. Availability could be transmitted to a 
user via conventional telephone lines. E-mail, facsimile or pager. A notification preference 
could be determined by the user during the registration process. 

Another aspect of ticket resale that is well suited to the present embodiment is 
advertising. Instead of simply allowing users to place, review and accept offers, the system 
could provide advertising for products related to events and tickets. 

CPO AND THIRD PARTY INPUT MAN AGENT SYSTEM 
The method and apparatus of another embodiment of the present 
invention, which allows sellers to evaluate the acceptability of an offer from a buyer in 
light of information relevant to the offer from a third party, will now be discussed with 
reference to Figures 74 through 82. Although the description which follows in 
conjunction with Figures 74 through 82 employs a finance-related embodiment for 
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purposes of illustration, those skilled in the art will understand that the scope of the 
present invention is not limited thereto. Accordingly, in the description below, sellers 
and buyers may be referred to as lenders and borrowers, respectively. 

Referring to Figure 74, a system 7410 for processing the sale of products 
comprises a central controller 7412 which communicates with a borrower terminal 
7414, third parties 7416 and 7418, and lender terminals 7420, 7422 and 7424 via the 
Internet or other suitable communication network. The illustrated numbers of borrower 
terminals, third parties and/or lender terminals are illustrative, not limiting. It will be 
understood by those skilled in the art that any number of borrower terminals, third 
parties and/or lender terminals may communicate with the central controller 7412 in 
alternate embodiments of the present invention. 

The borrower terminal 7414 is typically a computer or other apparatus 
for generating and transmitting signals to the central controller 7412. Ideally, the 
borrower terminal is a conventional personal computer, such as one based on an Intel 
80386 microprocessor, that is connected to a modem or other remote communication 
device. A customer desiring to purchase a product (good or service) operates the 
borrower terminal 7414 to transmit an offer signal including at least one condition 
signal to the central controller 741 2. The offer signal defines a conditional purchase 
offer having at least one condition from the customer. 

In the present embodiment, the customer is a "borrower" who desires to 
obtain a loan (i.e., he desires to "purchase" a loan). Accordingly, the offer signal 
defines an offer to obtain a loan. As described in detail below, the offer may comprise 
any of a variety of conditions, and so the offer signal comprises one or more condition 
signals specifying the borrower's desired conditions. For example, the borrower may 
desire a particular monthly payment amount for the loan and/or a particular interest rate. 

The borrower terminal 7414 also transmits to the central controller 7412 
a payment identifier signal for specifying a general-purpose account from which funds 
may be paid. The payment identifier signal specifies, for example, a credit card number 
or checking account number of an account owned by the borrower. 

The payment identifier signal is used to effectively "bind" the borrower 
by identifying funds to be paid if the borrower fails to carry out (consummate) his offer 
to purchase. The payment identifier thereby assures potential lenders that the offer is 
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genuine and binding. For example, if the borrower reneges, the payment identifier may 
be used to collect an amount of funds sufficient to offset the lender's costs in processing 
the borrower's offer. The specific amount of funds to collect can be either set by the 
central controller 7412, or may be left to the discretion of the lender. 
5 In other embodiments, the payment identifier may additionally be used to 

collect other fees, even if the borrower consummates his offer. For example, the 
payment identifier may be used to collect loan transaction fees or even monthly loan 
payments. 

If a lender operates a lender terminal to accept the offer, thereby 
10 incurring costs processing the offer, the lender is assured that he (i) may sell the loan to 
the borrower if he can satisfy the loan conditions; or (ii) if the borrower fails to abide by 
the terms of the offer (e.g., the borrower fails to consummate the loan), the lender 
collects a penalty payment paid from the account specified by the payment identifier 
signal. In both cases, the lender is assured that acceptance of the offer will yield funds, 
15 and thus acceptance of the offer is not as risky as in other systems for processing the 
sale of products. 

As described above, sellers often require information relevant to the offer 
from a third party in order to determine whether to accept the offer. For example, the 
offer signal from the borrower would not be evaluated and accepted by a lender unless 

20 the lender knew the borrower's credit history or credit score. Accordingly, the system 
7410 includes third parties 7416 and 7418 for providing the central controller 7412 with 
informational signals. The informational signals desirably define any information that 
(i) should not be viewed and/or altered by the buyer, and/or (ii) is necessary to 
determine the validity and/or value of the offer. The third parties 74 1 6 and 74 1 8 may 

25 be, for example, a credit-reporting bureau, which provides the central controller 74 1 2 
with credit information about the borrower, and an appraiser for appraising the value of 
loan collateral submitted by the borrower. 

The central controller 7412 receives and stores the transmitted offer 
signal, payment identifier signal and informational signal. As described in detail below, 

30 the signals are stored in several databases, thereby facilitating the searching for and 
retrieval of data represented in the databases. The central controller 74 1 2 uses the 
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stored signals to allow any of the lender terminals 7420, 7422 and 7424 to accept the 
offer, if the offer is considered adequate. 

If a lender terminal accepts the offer, the borrower is bound to abide by 
the terms of the offer. If the borrower does not, for example if the borrower does not 
sign the necessary loan paperwork, the central controller 7412 initiates the use of the 
payment identifier signal to collect the funds. For example, the central controller 7412 
may transmit the payment identifier signal to the lender terminal, thereby allowing the 
lender to collect the funds. Alternatively, the central controller 7412 may itself use the 
payment identifier signal to collect the funds. 

The central controller 7412 may manage the acceptance of offers in 
various ways. In embodiments described below, accepting an offer can include (i) 
transmitting the offer signal to lender terminals, and in turn receiving acceptance signals 
from lender terminals, or (ii) comparing the offer signal with seller's rules, and 
determining whether the offer satisfies any of the rules. 

Figure 75a illustrates a central controller 7530, which is an embodiment 
of the central controller 7412 (Figure 74) that is used when accepting an offer includes 
the step of receiving acceptance signals from lender terminals. The central controller 
7530 includes a central processing unit 753 1, such as one or more conventional 
microprocessors, and a storage device 7532, such as a RAM, floppy disk, hard disk or 
combination thereof, which is connected to the central processing unit 7531. The 
central processing unit 7531 and the storage device 7532 may each be (i) located 
entirely within a single computer: (ii) connected thereto by a remote communication 
link, such as a serial port cable, telephone line or radio frequency transceiver: or (iii) a 
combination thereof. For example, the central controller 7530 may comprise one or 
more computers connected to a remote server computer for maintaining databases. 

The storage device 7532 stores (i) a program 7533 for controlling the 
central processing unit 7531 in accordance with the present invention, and particularly 
in accordance with the processes described in detail hereinafter; (ii) a borrower database 
7534 for maintaining information on each borrower who submits an offer; (iii) a lender 
database 7536 for maintaining information on each lender who may accept an offer; (iv) 
an offer database 7538 for specifying each offer submitted to the central controller; (v) a 
credit report database 7540 for storing informational signals describing credit 
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worthiness; (vi) a collateral database 7542 for storing informational signals describing 
collateral used in connection with the offers; and (vii) a response database 7544 for 
specifying each acceptance received by the central controller. 

The program 7533 also includes necessary program elements, such as 
5 "device drivers" for interfacing with computer peripheral devices. Appropriate device 
drivers and other necessary program elements arc known to those skilled in the art, and 
need not be described in detail herein. Each of the databases 7534, 7536, 7538, 7540, 
7542 and 7544 are described in detail below. 

Figure 75b illustrates a central controller 7560, which is an embodiment 
10 of the central controller 7412 (Figure 74) that is used when accepting an offer includes 
the step of determining whether the offer satisfies any lender-specified rules. The 
central controller 7560 includes a central processing unit 7561 and a storage device 
7562 connected to the central processing unit 7561 . The central processing unit 756 1 
and the storage device 7562 may each be implemented in a manner similar to the central 
15 processing unit 753 1 and the storage device 7532 of Figure 75a. 

The storage device 7562 likewise stores (i) a program 7533 for 
controlling the central processing unit 7561 in accordance with the present invention; 
(ii) a borrower database 7534 for maintaining information on each borrower who 
submits an offer; (iii) a lender database 7536; (iv) an offer database 7538; (v) a credit 
20 report database 7540; and (vi) a collateral database 7542; and further stores (vii) a rules 
database 7564 for storing lender-specified rules for accepting offers. The program 7533 
and the databases 7534, 7536, 7538, 7540 and 7542 function as described above, and 
the rules database 7564 is described in detail below. 

Referring to Figure 76, the borrower database 7534 of Figures 75a and 
25 75b stores exemplary records 7670 and 7672, each of which corresponds to a borrower 
who submits an offer. Each record stores an offer identifier 7674 that is generated by 
the central controller 7412 (Figure 74) and uniquely identifies an offer made by the 
borrower. Each record also stores the name 7676, address 7678 and telephone number 
7680 of the borrower. 

30 Referring to Figure 77, the lender database 7536 of Figures 75a and 75b 

stores exemplary records 7790 and 7792, each of which corresponds to a lender who 
may accept an offer. Each record stores a lender identifier 7794 that is generated by the 
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central controller 7412 (Figure 74) and uniquely identifies a lender, as well as the name 
7796, address 7798 and telephone number 7800 of the lender. 

Referring to Figure 78, the offer database 7538 of Figures 75a and 75b 
stores exemplary records 7810, 7812 and 7814, each of which corresponds to a received 
offer. Each record stores an offer identifier 78 16 that (i) uniquely identifies an offer, 
and (ii) corresponds to one of the offer identifiers 7674 of the borrower database 7534 
of Figure 76. Each record further stores the date 78 1 8 and time 7820 at which the offer 
was received, and conditions of the offer, such as a loan amount 7822, a monthly 
payment 7824, a loan term 7826 and a loan interest rate 7828. Each record may also 
have an expiration date 7830 and expiration time 7832, after which the corresponding 
offer may not be accepted. A loan type 7834 may also be stored in embodiments where 
it is desirable for lenders to know, for example, whether the desired loan is secured. 

Referring to Figure 79, the credit report database 7540 of Figures 75a 
and 75b stores exemplary records 7942, 7944 and 7946, each of which corresponds to a 
received offer. Each record stores an offer identifier 7948 that (i) uniquely identifies an 
offer, (ii) corresponds to one of the offer identifiers 7674 of the borrower database 7534 
of Figure 76, and (iii) corresponds to one of the offer identifiers 7816 in the offer 
database 7538 of Figure 78. For each offer, there is also stored a credit report identifier 
7950 that is generated by the central controller 7412 (Figure 74) and uniquely identifies 
the results of a credit check or other evaluation of a borrower who submitted the 
corresponding offer. A credit score 7952 defines the results of that evaluation. 

Referring to Figure 80, the collateral database 7542 of Figures 75a and 
75b stores exemplary records 8060, 8062, 8064 and 8066, each of which corresponds to 
a received offer. Each record stores an offer identifier 8068 that uniquely identifies an 
offer and corresponds to the offer identifiers described above in connection with Figures 
76, 78 and 79. For each offer, there is also stored the type 8070 of collateral, a 
description 8072 of the collateral and a value 8074 of the collateral. 

Referring to Figure 8 1 a, the response database 7544 of Figure 75a stores 
exemplary records 8 1 80 and 8 1 82, each of which corresponds to a received response to 
an offer. Each record stores an offer identifier 8184 that uniquely identifies an offer and 
corresponds to the offer identifiers described above in connection with Figures 76, 78, 79 
and 80. Each record also stores a response identifier 8 1 86 that uniquely identifies each 
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received response, a lender identity 8188, and conditions of the loan that the lender is 
willing to provide, such as a loan amount 8190, a periodic payment amount 8 192, a loan 
term 8194 and a loan interest rate 8196. The time 8198 and date 8200 of the response 
are also stored in the response database 7544. 
5 Referring to Figure 81b, the rule database 7564 of Figure 75b stores 

exemplary records 8212 and 8214, each of which corresponds to a rule defining criteria 
for when a lender will accept an offer. Each record stores a rule identifier 82 1 6 that 
uniquely identifies a rule, a lender identity 8218 identifying the lender who accepts 
offers satisfying the rule and rule restrictions 8220 which specify the criteria for 
10 accepting an offer. 

Figures 82a and 82b illustrate a method 8230 for processing sales of a 
loan between a borrower terminal and one or more lender terminals. The illustrated 
method 8230 is performed by the central controller 7530 of the embodiment of Figure 
75a, in which accepting an offer includes receiving acceptance signals from lender 
15 terminals. The central controller receives from the borrower terminal an offer signal 
(step 8232). As described above, the offer signal includes at least one condition signal, 
and the offer signal thereby defines an offer having at least one condition from a 
borrower. 

A payment identifier signal is received from the borrower terminal (step 
20 8 234). The payment identifier signal, such as a credit card number or checking account 
number, specifies an account from which funds may be paid. 

The central controller validates the payment identifier signal (step 8236). 
The payment identifier signal may be validated by freezing an amount of funds in the 
account or otherwise making the funds unavailable to the borrower and thereby ensuring 
25 that such funds remain available to an accepting seller. If the payment identifier signal 
is not valid, the borrower terminal is requested to retransmit the offer and payment 
identifier signal (step 8238). The central controller also validates the received offer 
signal (step 8240), thereby determining whether the received offer signal meets 
predetermined validation criteria. If the offer signal does not meets the predetermined 
30 validation criteria, the borrower terminal is requested to retransmit the offer and 
payment identifier (step 8238). 
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Validation typically comprises performing a financial calculation to 
determine whether the received offer signal defines a meaningful offer. For example, if 
an offer signal includes a loan amount, interest rate, loan period and monthly payment 
amount, a financial calculation can determine whether the specified offer is meaningful. 
Financial calculations are known, and described in Chapter Three of "Principles of 
Corporate Finance, Fourth Edition", by Richard A. Brealey and Stewart C. Myers, 
incorporated herein by reference as part of the present disclosure. 
The central controller also requests and receives an informational signal including credit 
information from a third party (step 8242). The informational signal may further 
include other information relevant to the offer, such as an appraisal value of collateral 
offered by the borrower. As described above, more than a single third party may supply 
desired informational signals to the central controller. 

The central controller then transmits the offer signal and the 
informational signal(s) to one or more lender terminals (step 8244). The central 
controller in turn receives, from at least one of the lender terminals, one or more 
acceptance signals responsive to the transmitted offer signal and informational signal 
(step 8246). One of the acceptance signals is selected (step 8248), and the 
corresponding lender terminal is identified (step 8250). The borrower is thereby bound 
to the identified lender under the terms and conditions of the offer. If the borrower later 
reneges by not abiding by the terms of the offer (step 8252), use of the payment 
identifier signal is initiated in order to collect the funds (step 8254). For example, the 
central controller may collect the funds, or may transmit the payment identifier signal to 
the identified lender terminal, allowing the lender to directly collect the funds. 

The step 8248 of selecting one acceptance signal may be performed in a 
number of ways. For example, the first received acceptance signal or a random one of 
the acceptance signals may be selected. In still another embodiment, the acceptance 
signals may be sorted according to a predetermined sort criteria, such as sorted by 
lowest interest rate or lowest monthly payment amount. Selecting the first of the sorted 
acceptance signals would then provide the lowest interest rate or monthly payment, 
respectively. A number of "tie-breaking" methods may be used to select one acceptance 
signal from a group of equally attractive acceptance signals. 
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It may also be desirable to allow the borrower to select the acceptance 
signal, and thus choose the lender. In such an embodiment, a plurality of lender signals 
is transmitted to the borrower. Each lender signal indicates a lender, which in turn 
corresponds to one of the plurality of acceptance signals. The borrower terminal then 
5 provides the central controller with a selection signal indicative of a selected lender 
signal. The selection signal thereby indicates a corresponding acceptance signal, which 
is selected. 

Selection of an acceptance signal may also occur through a condition 
specified by the offer. For example, an offer may comprise condition signals indicative 

10 of a loan amount, a periodic payment amount and a request for a lowest interest rate. 
Thus, the acceptance signal indicating the lowest interest rate received within a 
predetermined time is selected. Similarly, an offer may comprise condition signals 
indicative of a loan amount, an interest rate and a request for a lowest periodic payment 
amount. Such an offer may further comprise a condition signal indicative of a 

15 maximum loan period. Accordingly, the acceptance signal indicating the lowest 
periodic payment amount is selected. 

Figure 82c illustrates another embodiment of a method 8260 for 
processing sales of a loan between a borrower terminal and one or more lender 
terminals. The illustrated method 8260 is performed by the central controller 7560 of 

20 the embodiment of Figure 75b, in which accepting an offer includes comparing the offer 
signal with seller's rules, and determining whether the offer satisfies any of the rules. 

As described above in connection with Figures 82a and 82b, the central 
controller receives from the borrower terminal an offer signal (step 8262), and also 
receives a payment identifier signal (step 8264). The central controller validates the 

25 payment identifier signal (step 8266). If the payment identifier is not valid, the borrower 
terminal is requested to retransmit the offer and payment identifier (step 8268). The 
central controller also validates the received offer signal (step 8270), thereby 
determining whether the received offer signal meets predetermined validation criteria. If 
the offer is not meaningful, the borrower terminal is requested to retransmit the offer and 

30 payment identifier (step 8268). The central controller also requests and receives an 
informational signal including credit information from a third party (step 8272). 
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20 



The central controller stores at least one rule signal from each of a 
plurality of sellers (step 8274). Each rule signal includes at least one seller-defined 
restriction. Some restrictions may involve offer conditions, while other restrictions may 
involve the informational signal. For example, a rule may include the restrictions that 
5 the loan amount must be less than $ 1 00,000 and the credit score must be greater than 
eighty. It will be understood by those skilled in the art that the step 8274 of storing the 
rule signals may occur either before or after the offer signal is received. 

The offer signal and the informational signal are compared with at least 
one rule signal (step 8276). If it is determined that the conditions of the offer and the 
10 informational signal satisfy each seller-defined restriction of any rule (step 8278), the 
corresponding lender is identified (step 8280). If more than one rule is satisfied, one 
rule is selected in accordance with any of the methods described above. The borrower 
is thereby bound to the identified lender under the terms and conditions of the offer. If 
the borrower later reneges by not abiding by the terms of the offer (step 8282), use of 
the payment identifier signal is initiated in order to collect the funds (step 8284), as 
described above. 

Those skilled in the art will recognize that the method and apparatus of 
the present invention has many applications, and that the present invention is not limited 
to the representative examples disclosed herein. Moreover, the scope of the present 
invention covers conventionally known variations and modifications to the system 
components described herein, as would be known by those skilled in the art. 



15 
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WHAT IS CLAIMED: 

1 1 A computer device for consummating a binding contract between a 

5 remote prospective buyer and a remote potential seller, comprising: 
a memory device; and 

a processor disposed in communication with said memory device, said 
processor configured to receive from the remote prospective buyer (a) a purchase offer 
containing at least one condition, and (b) a payment identifier for specifying a general 
10 purpose financial account from which funds may be paid for a purchase meeting said at 
least one condition; said processor further configured to transmit the purchase offer to a 
plurality of remote potential sellers, and receive from at least one of the remote potential 
sellers an unconditional acceptance of the offer. 

15 2. The computer device of claim 1, wherein said processor is 

further configured to initiate the use of the payment identifier to effect payment for the 
purchase from the buyer. 

3. The computer device of claim 1 , wherein the general purpose financial 
20 account is a credit card account. 

4. A computer device for consummating a binding contract between a 
remote prospective buyer and a remote potential seller, comprising: 

a memory device; and 

25 a processor disposed in communication with said memory device, said 

processor configured to receive from the remote prospective buyer (a) a purchase offer 
containing at least one condition, and (b) a payment identifier for specifying a general 
purpose financial account of an electronic settlement system from which funds may be 
paid for a purchase meeting said at least one condition; said processor further 

30 configured to transmit the purchase offer to an electronic buying network of remote 
potential sellers, receive from at least one of the remote potential sellers an 
unconditional acceptance of the offer, and initiate the use of the payment identifier to 
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render payment for said purchase by charging said general purpose financial account of 
said electronic settlement system. 

5- The computer device of claim 4 wherein said electronic settlement 
system is a credit card system. 

6 - Tne computer device of claim 4 wherein said electronic settlement 
system is separate from said electronic buying network. 

7. The computer device of claims 1 or 4, wherein the at least one condition 

is selected from the group consisting of price, quantity, delivery date, quality, 
geographic location, and anonymity. 

8 - The computer device of claims I or 4, wherein the processor is 
configured to notify a first-accepting seller that it has entered into a legally binding 
contract with the buyer. 

9 - Tne computer device of claims 1 or 4, wherein the processor is further 
configured to transmit notification to the buyer that the purchase offer was accepted by 
a first-accepting seller. 

10. The computer device of claim 9, wherein the notification to the buyer of 

acceptance identifies a first-accepting seller. 

1 1 • Tne computer device of claims 1 or 4, wherein the purchase offer 

includes an expiration date and is non-revocable prior to that date. 

12. The computer device of claims 1 or 4, wherein the purchase offer expires 

if it is not accepted within a predetermined time period. 
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13 The computer device of claims I or 4, wherein the processor is further 

configured to notify the buyer that the purchase offer has lapsed if the purchase offer 
expires without being accepted. 

5 14 The computer device of claims 1 or 4, wherein the purchase offer is not 

valid until a predetermined date. 

15 The computer device of claims 1 or 4, wherein the processor is further 
configured to determine whether the offer has been revoked prior to any acceptance. 

10 

16 The computer device of claims 1 or 4, wherein the purchase offer 
contains the condition that the buyer has the right to withdraw its offer after the first- 
accepting seller accepts the offer provided that the buyer pays a specified penalty to the 
first-accepting seller. 

15 

17 The computer device of claims 1 or 4, wherein the purchase offer is 
cryptographically signed by the prospective buyer. 

Ig The computer device of claims 1 or 4, wherein the processor is further 

20 configured to collect payment for the purchase from the buyer. 

19 The computer device of claims 1 or 4, wherein the processor is further 

configured to transmit buyer credit card information and authorization to the first- 
accepting seller. 

25 

20. The computer device of claims 1 or 4, wherein the processor is further 

configured to place payment collected from the buyer in an escrow account. 

2i The computer device of claims 1 or 4, wherein the payment for the 

30 purchase is collected from the buyer on an installment basis. 



150 



WO 98/10361 



PCTYUS97/15492 



22. The computer device of claims I or 4, wherein the processor is further 

configured to remit payment for the purchase to the first-accepting seller. 

23> Tne computer device of claims I or 4. wherein the processor is further 

configured to transfer payment from the buyer to the first-accepting seller. 

24. The computer device of claim 23, wherein the payment for the purchase 

is remitted to the first-accepting seller immediately upon acceptance of the purchase 
offer. 



25 - The computer device of claims 1 or 4, wherein the processor is further 

configured to authenticate at least one of the origin and integrity of transmissions 
exchanged between the potential buyer and potential sellers. 

26. The computer device of claims 1 or 4, wherein the processor is further 
configured to make the purchase offer available to potential sellers without identifying 
the prospective buyer. 

27. The computer device of claims 1 or 4, wherein the processor is further 
configured to notify the buyer that their offer was accepted without revealing the 
identity of the seller. 



28. The computer device of claims I or 4, wherein the purchase offer is for 
goods. 

29. A method of electronically consummating a binding contract between a 
remote prospective buyer and a remote potential seller, which comprises the steps of: 

electronically receiving from the remote prospective buyer (a) a purchase 
offer containing at least one condition, and (b) a payment identifier for specifying a 
general purpose financial account from which funds may be paid for a purchase meeting 
said at least one condition; 
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electronically making available the purchase offer to a plurality of 
remote potential sellers; and 

electronically receiving from at least one of the remote potential sellers 
an unconditional acceptance of the offer. 

5 

30. The method of claim 29, wherein the at least one condition is selected 

from the group consisting of price, quantity, delivery date, quality, geographic location, 
and anonymity. 

jo 31, A method of electronically consummating a binding contract between a 

remote prospective buyer and a remote potential seller, which comprises the steps of: 

electronically receiving from the prospective buyer a purchase offer 
containing at least two conditions, one condition stating that the buyer shall have the 
right to choose from among a plurality of acceptances from potential sellers at least one 
15 acceptance to which the prospective buyer shall be bound; 

electronically making available the purchase offer to a plurality of 

potential sellers; 

electronically receiving from a plurality of the potential sellers 

unconditional acceptances of the offer; 
20 electronically transmitting the plurality of unconditional acceptances to 

the prospective buyer; and 

electronically receiving from the prospective buyer at least one election 
of an unconditional acceptance under which the buyer will be bound to perform. 

25 32. The method of claim 3 1 , wherein one of said two conditions is selected 

from the group consisting of price, quantity, delivery date, quality, geographic location, 
and anonymity. 

33. A method of electronically consummating a binding contract between a 

30 remote prospective buyer and a remote potential seller, which comprises the steps of: 

electronically receiving from the remote prospective buyer (a) a purchase 
offer containing at least one condition, and (b) a payment identifier from a general 
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purpose financial account of an electronic settlement system from which funds may be 
paid for a purchase meeting said at least one condition; 

electronically making available the purchase offer to a electronic buying 
network of remote potential sellers; 

electronically receiving from at least one of the remote potential sellers 
an unconditional acceptance of the offer; and 

electronically initiating use of the payment identifier to render payment 
for said purchase by charging said general purpose financial account of said electronic 
settlement system. 

34. The method of claim 33 wherein said electronic settlement system is a 
credit card system. 

35. The method of claim 33 wherein said electronic settlement system is 
separate from said electronic buying network. 

36. The method of claim 33, wherein the at least one condition is selected 
from the group consisting of price, quantity, delivery date, quality, geographic location, 
and anonymity. 

37. A system for processing airline ticket sales, comprising: 

a communications port for obtaining a purchase offer for travel from a 
customer and one or more rules from a plurality of sellers of airline tickets, said 
purchase offer containing at least one customer-defined condition and each of said rules 
containing one or more airline-defined restrictions; and 

processing means for comparing said purchase offer to said rules to 
determine whether any of said sellers of airline tickets is willing to accept said purchase 
offer if said customer-defined conditions satisfy said airline-defined restrictions of at 
least one of said rules. 

38. A system for processing the sale of goods or services, comprising: 
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a communications port for obtaining a purchase offer from a customer 
for the purchase of said goods or services and one or more rules from a plurality of 
sellers, said purchase offer containing at least one customer-defined condition and each 
of said rules containing one or more seller-defined restrictions; and 
5 a processor for comparing said purchase offer to said rules to determine 

whether any of said sellers is willing to accept said purchase offer if said customer- 
defined conditions satisfy said seller-defined restrictions of at least one of said rules. 

39. The system according to claim 37 or 38, wherein said purchase offer is 
10 binding. 

40. The system according to claim 37 or 38, wherein said processor 
identifies a product satisfying said customer-defined conditions. 

15 41 . The system according to claim 37 or 38, wherein said restrictions include 

a price and said price is not disclosed. 

42. The system according to claim 37 or 38, wherein said processor 
provides an acceptance of said purchase offer to said customer if said customer-defined 

20 conditions satisfy said restrictions. 

43. The system according to claim 37 or 38, wherein said processor binds 
said customer if said customer-defined conditions satisfy said restrictions. 

25 44. The system according to claim 37 or 38, further comprising one or more 

remote servers for storing at least a portion of said rules. 

45. The system according to claim 37 or 38, further comprising at least one 

revenue management system and wherein at least a portion of said rules are generated 
30 by said at least one revenue management system. 
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46. The system according to claim 37 or 38, wherein said processor 
generates a counteroffer if said purchase offer is noi accepted and said purchase offer is 
within a predefined tolerance of at least one of said rules. 

47. The system according to claim 37 or 38, wherein said restrictions include 
a minimum price and said processor prevents said customer from identifying said 
minimum price. 

48. The system according to claim 47, wherein said processor prevents said 
customer from identifying said minimum price by limiting the number of said purchase 
offers which may be obtained from a given customer in a predefined period. 

49. The system according to claim 47, wherein said processor prevents said 
customer from identifying said minimum price by assessing a penalty to said customer 
if a ticket is not booked when an airline accepts said purchase offer. 

50. The system according to claim 47, wherein said processor prevents said 
customer from identifying said minimum price by evaluating a rating of said customer 
containing information regarding the likelihood that said customer will book a ticket 
corresponding to said purchase offer. 

5 1 . The system according to claim 47 t wherein said processor prevents said 
customer from identifying said minimum price by binding said customer to purchase 
said airline ticket if said customer-defined conditions satisfy said airline-defined 
restrictions. 

52. A system for processing the sale of airline tickets, said system 
comprising; 

an inventory allocation system for providing a plurality of seats for sale 
to customers who submit a purchase offer for travel, said purchase offer containing at 
least one customer-defined condition including a price; 
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a revenue management system for establishing airline-defined 
restrictions that are applicable to said provided seats including an appropriate fare; and 

a transmitter for providing said airline-defined restrictions to a processor 
to determine whether to accept said purchase offer if said customer-defined conditions 
5 satisfy said airline-defined restrictions. 

53. The system according to claim 52, a receiver for obtaining a reservation 
for one or more of said provided seats if said customer-defined conditions satisfy said 
airline-defined restrictions. 

10 

54. The system according to claim 52, wherein said revenue management 
system allocates a fare class containing said plurality of seats for sale to said customers 
who submit said purchase offer. 

15 55. The system according to claim 52, wherein said revenue management 

system further comprises a processor for establishing rules for generating a 
counteroffer if said purchase offer is within a predefined tolerance of at least one of said 
airline-defined restrictions. 

20 56. The system according to claim 52, wherein said revenue management 

system selects said airline-defined restrictions to discourage use by customers typically 
willing to pay full fare. 

57. A method of processing airline ticket sales, comprising the steps of: 

25 obtaining a purchase offer for.travel from a customer, said purchase offer 

containing at least one customer-defined condition including a price; 

identifying one or more rules from a plurality of sellers of airline tickets, 
each of said rules containing one or more airline-defined restrictions; and 

comparing said purchase offer to said rules to determine whether any of 
30 said sellers of airline tickets is willing to accept said purchase offer if said customer- 
defined conditions satisfy said airline-defined restrictions of at least one of said rules. 
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58. A system for processing cruise ticket sales, comprising: 

a communication port for obtaining a purchase offer for travel from a 

customer and for receiving one or more rules from a plurality of sellers of cruise tickets, 

said purchase offer containing at least one customer-defined condition including a price 
5 and each of said rules containing one or more cruise operator-defined restrictions; and 

a processor for comparing said purchase offer to said rules to determine 

whether said customer-defined condition satisfies each of said cruise operator-defined 

restrictions of at least one of said rules. 

10 59. A system for processing cruise ticket sales comprising: 

a communications port for obtaining a purchase offer for said cruise 
ticket from a customer and for providing said purchase offer to a plurality of potential 
sellers of said cruise tickets, said purchase offer containing at least one customer- 
defined condition and a payment identifier for specifying a general-purpose account 
15 from which funds may be paid; and 

a processor for determining if one or more of said carriers accepts said 
purchase offer and for binding said customer to purchase said cruise ticket if an 
acceptance is received for said purchase offer. 

20 60. The system according to claim 58, wherein said cruise operator-defined 

restrictions include a price and said price is not disclosed. 

61. The system according to claim 58 or 59, wherein said customer-defined 
condition includes a specified itinerary. 

25 

62. The system according to claim 58 or 59, wherein said customer-defined 
condition includes a level of service. 

63. The system according to claim 58 or 59, wherein said customer-defined 
30 condition includes a maximum price. 

64. A system for processing the sale of a product, comprising: 
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a communication port for obtaining a purchase offer for said product 
from a customer, said purchase offer containing at least one customer-defined condition 
and a payment identifier for specifying a general-purpose account from which funds 
may be paid; 

5 a processor for determining if a plurality of potential sellers of said 

product accept said purchase offer and for identifying said plurality of accepting sellers 
to said customer; and 

said communication port receiving a selection from said customer of one 
of said accepting sellers to provide said product. 

10 

65. The system according to claim 64, wherein said processor provides a 
channel of communication between said buyer and said accepting sellers. 

66. The system according to claim 64, wherein said processor provides an 
15 electronic representation to said buyer of said product provided by each of said 

accepting sellers. 

67. The system according to claim 64, wherein said processor provides 
incentives to said buyer for selecting one of said accepting sellers to provide said 

20 product. 

68. A system for processing the sale of a product comprising: 

a communications port for obtaining a purchase offer from a customer, 
said purchase offer containing at least one customer-defined condition and a payment 
25 identifier for specifying a general-purpose account from which funds may be paid; and 

a processor for (i) determining if one or more of said carriers accepts said 
purchase offer and identifies a product satisfying said customer-defined condition and 
(ii) binding said customer to purchase said cruise ticket if an acceptance is received for 
said purchase offer. 

30 
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69. A system for processing the sale of a product, comprising: 

a communications port for obtaining a purchase offer from a customer, 
said purchase offer containing at least one customer-defined condition and a payment 
identifier for specifying a general-purpose account from which funds may be paid; 
5 a processor for determining if a plurality of potential sellers accept said 

purchase offer and for binding said customer to purchase from one of said plurality of 
accepting sellers; and 

a memory device for storing an identifier of said additional acceptances 
for comparison by said processor against purchase offers from subsequent customers. 

10 

70. The system according to claim 69, wherein said identifier of said 
additional accepted products is stored in a memory cache which is accessed before said 
providing step for said purchase offers from subsequent customers. 

15 71. A system for processing the sale of a product, comprising: 

a communications port for: 

(a) obtaining a purchase offer from a customer for the purchase of said 
product, said purchase offer containing at least one customer-defined 
condition including a subset of preferred sellers from a set of 
potential sellers; 

(b) providing said purchase offer to one or more excluded sellers in said 
set of potential sellers who are not preferred sellers; and 

(c) receiving from one of said excluded sellers a counteroffer to said 
purchase offer before said purchase offer is accepted by one of said 
preferred sellers; and 

a processor for determining if said customer accepts said counteroffer. 

72. The system according to claim 71, wherein said communication port 

receives an acceptance from said customer to purchase said product from said excluded 
counteroffering seller. 
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73. The system according to claim 71, wherein said processor binds said 
customer to purchase said product from said excluded counteroffering seller. 

74. The system according to claim 71, wherein said purchase offer is 
5 provided to said excluded sellers before said preferred sellers. 

75. The system according to claim 71, wherein said purchase offer is 
provided to said excluded sellers contemporaneously wilh said preferred sellers. 

10 76. The system according to claim 64, 68, 69 or 7 1 , wherein said product is a 

good or service. 

77. The system according to claim 76, wherein said good or service is an 
airline ticket. 

15 

78. The system according to claim 76, wherein said good or service is a 
cruise. 

79. The system according to claim 76, wherein said good or service is one or 
20 more long distance telephone calls. 

80. A method of processing cruise ticket sales, comprising the steps of: 
obtaining a purchase offer for travel from a customer, said purchase offer 

containing at least one customer-defined condition; 
25 identifying one or more rules from a plurality of sellers of cruise tickets, 

each of said rules containing one or more cruise operator-defined restrictions; and 

binding said customer to purchase said cruise ticket if said customer- 
defined condition satisfies each of said cruise operator-defined restrictions of at least 
one of said rules. 

30 

81. A method of processing cruise ticket sales, comprising the steps of: 
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obtaining a purchase offer for said cruise ticket from a customer, said 
purchase offer containing at least one customer-defined condition and a payment 
identifier for specifying a general-purpose account from which funds may be paid; 

providing said purchase offer to a plurality of potential sellers of said 

cruise tickets; 

receiving from one or more of said sellers an acceptance of said purchase 

offer; and 

binding said customer to purchase said cruise ticket if an acceptance is 
received for said purchase offer. 

82. A system for processing the sale of a package of component items 
comprising: 

a communications port to receive a purchase offer for said package from 
a customer, said purchase offer containing a description of each component item and a 
payment identifier for specifying a general-purpose account from which funds may be 
paid; and 

a processor to deconstruct said package purchase offer into a plurality of 
component purchase offers and to determine if each of said component purchase offers 
are accepted by one or more potential sellers and thereby bind said customer to purchase 
said package if an acceptance is received for each of said component purchase offers. 

83. A system for processing the sale of a package of component items 
comprising: 

a communications port for obtaining a purchase offer for said package 
from a customer and for obtaining one or more rules from a plurality of sellers of said 
component items, said purchase offer containing at least one customer-defined 
condition for each of said component items and each of said rules containing one or 
more seller-defined restrictions; and 

a processor to: 

deconstruct said package purchase offer into a plurality of component 
purchase offers; 
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compare one or more of said component purchase offers to said rules to 
determine whether any of said sellers is willing to accept said component purchase offer 
if said customer-defined condition satisfies said seller-defined restrictions of at least one 
of said rules; and 



5 provide said package of component items to said customer if an 

acceptance is obtained for each of said component purchase offers. 

84. A system for processing the sale of a package of component items 

comprising: 

10 a communications port to receive a purchase offer for said package from 



a customer, said purchase offer containing a description of each component item and a 
payment identifier for specifying a general-purpose account from which funds may be 
paid; and 

a processor to determine if each of said component purchase offers are 
15 accepted by one or more potential sellers and thereby bind said customer to purchase 
said package if an acceptance is received for each of said component purchase offers. 

85. The system according to claim 82 or 84, wherein said processor initiates 
the use of said payment identifier to collect said funds. 

20 

86. The system according to claim 82, 83 or 84, wherein said component 
purchase offers are offered at a component price. 

87. The system according to claim 86, wherein said component price of each 
25 component is based on the percentage of the market value of the component item to the 

market value of the total package. 

88. The system according to claim 82, 83 or 84, wherein said processor 
initiates the entering of a preliminary agreement with each seller accepting a component 

30 purchase offer, whereby the component item associated with said accepted component 
purchase offer is reserved for a predefined time period. 
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89. The system according to claim 82, 83 or 84, wherein said purchase offer 
includes a total price and a portion of said total price is reserved as a margin. 

90. The system according to claim 86, wherein said processor increases the 
5 component price of one or more of said component purchase offers that remain 

unaccepted by said sellers after a predefined time period. 

91. The system according to claim 82, 83 or 84, wherein said processor 
filters said component purchase offers provided to said sellers based on the industry 

10 associated with each component purchase offer and the industry of said sellers. 

92. The system according lo claim 82, 83 or 84, wherein said acceptance 
further includes an identification of a component product satisfying said customer- 
defined condition. 

15 

93. A system for processing the sale of a package of component items 
comprising: 

a communications port to receive a purchase offer for said package from 
a customer, said purchase offer containing a description of each component item and a 
20 payment identifier for specifying a general-purpose account from which funds may be 
paid; and 

a processor to deconstruct said package purchase offer into a plurality of 
component purchase offers and to determine if each of said component purchase offers 
are accepted by one or more potential sellers at a component price and thereby bind said 
25 customer to purchase said package if an acceptance is received for each of said 
component purchase offers, wherein said component prices are not disclosed to said 
customer. 

94. A method of processing the sale of a package of component items, 
30 comprising the steps of: 
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obtaining a purchase offer for said package from a customer, said 
purchase offer containing a description of each component item and a payment 
identifier for specifying a general-purpose account from which funds may be paid; 

deconstructing said package purchase offer into a plurality of component 
5 purchase offers; 

determining if one or more potential sellers accept said component 
purchase offers; and 

binding said customer to purchase said package if an acceptance is 
received for each of said component purchase offers. 

10 

95. A method of processing the sale of a package of component items, 
comprising the steps of: 

obtaining a purchase offer for said package from a customer, said 
purchase offer containing at least one customer-defined condition for each of said 
15 component items; 

deconstructing said package purchase offer into a plurality of component 

purchase offers; 

identifying one or more rules from a plurality of sellers of said 
component items, each of said rules containing one or more seller-defined restrictions; 
20 and 

comparing one or more of said component purchase offers to said rules 
to determine whether any of said sellers is willing to accept said component purchase 
offer if said customer-defined condition satisfies said seller-defined restrictions of at 
least one of said rules; and 
25 providing said package of component items to said customer if an 

acceptance is obtained for each of said component purchase offers. 

96. A system for processing long distance calls comprising: 

a communications port for obtaining a purchase offer from a customer 
30 for one or more telephone calls and for providing said purchase offer to a plurality of 
potential carriers, said purchase offer containing at least one customer-defined condition 
and a payment identifier for specifying a manner in which funds will be paid; and 
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a processor for determining if one or more of said carriers accepts said 
purchase offer and for binding said customer to purchase said telephone calls if an 
acceptance is received for said purchase offer. 

97. A system for processing long distance calls, comprising: 

a communication port for obtaining a purchase offer from a customer for 
one or more telephone calls and for receiving one or more rules from a plurality of 
carriers, said purchase offer containing at least one customer-defined condition 
including a price and each of said rules containing one or more carrier-defined 
restrictions; and 

a processor for comparing said purchase offer to said rules to determine 
whether any of said carriers is willing to accept said purchase offer if said customer- 
defined condition satisfies each of said carrier-defined restrictions of ai least one of said 
rules. 

98. The system according to claim 96, wherein said processor initiates 
the use of said payment identifier to collect payment. 

99. The system according to claim 96, wherein said funds may be paid 
from a general purpose account. 

100. The system according to claim 96, wherein said funds are charged 
to a periodic telephone service bill issued by a telephone service provider. 

101. The system according to claim 96 or 97, wherein said purchase offer is 
received from a telephone set configured to transmit said purchase offers. 

102. The system according to claim 96 or 97, wherein said purchase offer is 
for a package of calls to one or more called parties. 

103. The system according to claim 96 or 97, wherein said purchase offer is 
for a telephone service contract for a predefined period of time. 
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104. The system according to claim 96 or 97, wherein said purchase offer is 

for a telephone service contract for a predefined amount of money. 

5 105. The system according to claim 96 or 97, wherein said customer-defined 

condition specifies a particular time of day for said one or more telephone calls. 

106. The system according to claim 96 or 97, wherein said customer-defined 
condition specifies a minimum duration for said one or more telephone calls. 

10 

107. The system according to claim 96 or 97, wherein said customer-defined 
condition specifies a maximum duration for said one or more telephone calls. 

108. The system according to claim 96 or 97, wherein said customer-defined 
15 condition includes a telephone number of a party to be called. 

109. The system according to claim 96 or 97, wherein said communication 
port is connected to a telephone network. 

20 1 10. The system according to claim 96 or 97, wherein said communication 

port is connected to an electronic network. 

HI. A method of processing long distance calls, comprising the steps of: 

obtaining a purchase offer from a customer for one or more telephone 
25 calls, said purchase offer containing at least one customer-defined condition and a 

payment identifier for specifying a manner in which funds will be paid; 

providing said purchase offer to a plurality of potential carriers; 
receiving from one or more of said carriers an acceptance of said 

purchase offer; and 

30 binding said customer to purchase said telephone calls if an acceptance is 

received for said purchase offer. 
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112. A method of processing long distance calls, comprising the steps of: 
obtaining a purchase offer from a customer for one or more telephone 

calls, said purchase offer containing at least one customer-defined condition including a 
price: 

identifying one or more rules from a plurality of long distance carriers, 
each of said rules containing one or more carrier-defined restrictions: and 

binding said customer to purchase said telephone calls if said customer- 
defined condition satisfies each of said carrier-defined restrictions of at least one of said 
rules. 

113. A computer device for consummating a binding contract between a remote 
prospective event ticket buyer and a remote potential event ticket seller, comprising: 

a memory device: and 

a processor disposed in connection with said memory device, said 
processor configured to: 

receive from said buyer a purchase offer for an event ticket, said 
offer containing at least one condition, an account number from a general 
purpose financial account, and authorization to charge said general purpose 
financial account for a purchase meeting said at least one condition; 

transmit said purchase offer to a plurality of remote potential event ticket sellers 

receive from at least one of said remote potential event ticket sellers an 
unconditional acceptance of said offer: 

determine a replacement ticket identifier associated with said event ticket: and 

transmit said replacement ticket identifier to said buyer. 

1 14. The device of claim 1 1 3 wherein said processor is further configured to receive 
a second general purpose financial account number from said seller and authorization to charge 
said second general purpose account number for a penalty applied to an account of said seller. 

1 15. The device of claim 1 1 3 wherein said processor is further configured to process 
payment to said seller upon receiving a signal representing surrender of said event ticket by 
said seller. 
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116. The device of claim 1 13 wherein said processor is further configured to process 

payment to said seller upon receiving a ticket number associated with said event ticket. 

U7 The device of claim 1 13 wherein said processor is further configured to process 

a cancellation of said event ticket. 

1 1 g The device of claim 1 1 3 wherein said processor is further configured to receive 

and store a name of said buyer associated with said event ticket. 

1 19. The device of claim 113 wherein said processor is further configured to transmit 
to a venue controller a ticket identifier associated with said event ticket. 

120. The device of claim 1 19 wherein said processor is configured determine said 
replacement ticket identifier by being further configured to receive said replacement ticket 
identifier from said venue controller. 

121. The device of claim. 1 1 3 wherein said replacement ticket identifier includes an 
original ticket identifier. 

[ 22. A computer device for managing replacement identifiers for event tickets, 

comprising: 

a memory device; and 

a processor disposed in connection with said memory device, said processor 
configured to receive from a central controller a request for a replacement ticket number, said 
request including an original ticket number; said processor further configured to determine said 
replacement ticket number, transmit said replacement ticket number to said central controller; 
and store said original ticket number and said associated replacement ticket number at said 
memory device. 

123. The device of claim 122 wherein said processor is further configured to receive 
identity data representing an identity of a buyer, and store said identity data at said 
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memory device for association with said original ticket number and said replacement 
ticket number. 

1 24. A computer device for authenticating replacement identifiers for event tickets. 
5 comprising: 

a memory device for storing a ticket identifier and a first replacement ticket 
identifier associated with said ticket identifier; 
an output device; and 

a processor disposed in connection with said memory device and said output 
10 device, said processor configured to: 

electronically receive a second replacement ticket identifier: 

compare said second replacement ticket identifier to said first replacement ticket 
identifier to determine a result: and 

display said result via said output device to indicate the validity of said second 
1 5 replacement ticket identifier. 

125. The device of claim 124 wherein said memory further stores data representing 
an identity of a buyer associated with said first replacement ticket identifier, and said processor 
is further configured to retrieve said identity data and display said identity data via said output 

20 device to indicate said identity of said buyer. 

126. A method of processing sales of items, comprising: 

receiving an offer signal including at least one condition signal, the offer 
25 signal thereby defining an offer having at least one condition from a customer; 

receiving a payment identifier signal for specifying an account from 
which funds may be paid; 

receiving an informational signal relevant to the offer from a third party; 
transmitting the offer signal and the informational signal to at least one 

30 seller; 

receiving from at least one of the at least one seller an acceptance signal 
responsive to the transmitted offer signal and the transmitted informational signal: and 
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selecting one acceptance signal. 



127. An apparatus for processing sales or items, comprising: 
a storage device; and 

5 a processor connected to the storage device, 

the storage device storing a program for controlling the processor; and 
the processor operative with the program to: 

receive an offer signal including at least one condition signal, the 
offer signal thereby defining an offer having at least one condition from a 
!0 customer, 

receive a payment identifier signal for specifying an account from 
which funds may be paid, 

receive an informational signal relevant to the offer from a third 

party, 

15 transmit the offer signal and the informational signal to at least 

one seller, 

receive from at least one of the at least one seller an acceptance 
signal responsive to the transmitted offer signal and the transmitted 
informational signal, and 
20 selecting one acceptance signal. 

128. The apparatus of claim 127, wherein the processor is further operative 
with the program to: 

identify the seller from which the selected acceptance signal was 

25 received. 

129. The apparatus of claim 1 27, wherein the processor is further operative 
with the program to: 

initiate the use of the payment identifier signal to collect the funds. 

30 

130. The apparatus of claim 129, wherein the processor is further operative 
with the program to transmit the payment identifier signal to the at least one seller. 
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131. The apparatus of claim 1 27, wherein the processor is further operative 
with the program to: 

validate the received offer signal, and thereby determine whether the 
5 received offer signal meets predetermined validation criteria. 

132. The apparatus of claim 131, wherein the processor is further operative 
with the program to transmit the offer signal and the informational signal only if the 
step of validating determines that the received offer signal meets the predetermined 

10 validation criteria. 

133. The apparatus of claim 127, wherein the processor is further operative 
with the program to select the first received acceptance signal. 

15 1 34. The apparatus of claim 1 27, wherein the processor is further operative 

with the program to select a random one of the plurality of acceptance signals if a 
plurality of acceptance signals are received. 

135. The apparatus of claim 127, wherein the processor is further operative 
20 with the program to 

if a plurality of acceptance signals are received, 

sort the plurality of acceptance signals according to a 
predetermined sort criteria, and 

select the first of the sorted plurality of acceptance signals. 

25 

136. The apparatus of claim 127, wherein the processor is further operative 
with the program to 

if a plurality of acceptance signals are received, 

transmit a plurality of seller signals, each indicative of a seller 
30 which corresponds to one of the plurality of acceptance signals, 

receive a selection signal indicative of a selected seller signal, 
and thereby indicate a corresponding acceptance signal, and 
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select the acceptance signal corresponding to the selected seller signal. 

137. An apparatus for processing sales of a loan between a borrower terminal 
and at least one lender terminal, comprising: 

5 a storage device; and 

a processor connected to the storage device, the borrower terminal and 
the at least one lender terminal, 

the storage device storing 

a program for controlling the processor; and 
10 the processor operative with the program to 

receive from the borrower terminal an offer signal including at 
least one condition signal, the offer signal thereby defining an offer having at least one 
condition from a borrower, 

receive from the borrower terminal a payment identifier signal for 
15 specifying an account from which funds may be paid, 

receive an informational signal including credit information from 

a third party, 

transmit the offer signal and the informational signal to the at 
least one lender terminal, 
20 receive from at least one lender terminal an acceptance signal 

responsive to the transmitted offer signal and the transmitted informational signal, 
select one acceptance signal, and 

identify the lender terminal from which the selected acceptance 

signal was received. 

25 

138. The apparatus of claim 137, wherein the processor is further operative 
with the program to; 

validate the received offer signal, and thereby determine whether the 
received offer signal meets predetermined validation criteria. 

30 

139. The apparatus of claim 138, wherein the processor is further operative 
with the program to: 
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perform a financial calculation to determine whether the received offer 
signal defines a meaningful offer. 

140. The apparatus of claim 1 37, wherein the at least one condition signal 

indicates at least one of a loan amount, a periodic payment amount, a loan period and < 
interest rate. 



141. The apparatus of claim 1 37, wherein the at least one condition signal 

indicates a request for a lowest of one of a periodic payment amount and an interest 
rate. 



142. The apparatus of claim 137, wherein the offer signal includes: 
a first condition signal indicative of a loan amount, 

a second condition signal indicative of a periodic payment amount, and 
a third condition signal indicative of a request for a lowest interest rate. 

143. The apparatus of claim 142, wherein the processor is further operative 
with the program to: 

if a plurality of acceptance signals are received, wherein each acceptance 
signal includes an interest rate, select an acceptance signal having the lowest interest 
rate of the plurality of acceptance signals. 

144. The apparatus of claim 137, wherein the offer signal includes: 
a first condition signal indicative of a loan amount, 

a second condition signal indicative of a request for a lowest periodic 
payment amount, and 

a third condition signal indicative of an interest rate. 

145. The apparatus of claim 144, wherein the processor is further operative 
with the program to: 
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10 



15 



if a plurality of acceptance signals are received, wherein each acceptance 
signal includes a periodic payment amount, select an acceptance signal having the 
lowest periodic payment amount of the plurality of acceptance signals. 

146. The apparatus of claim 144, wherein the offer signal further includes: 
a fourth condition signal indicative of a loan period. 

147. The apparatus of claim 144, wherein the offer signal further includes: 
a fourth condition signal indicative of a maximum loan period. 

148. The apparatus of claim 1 37, wherein the offer signal includes: 
a first condition signal indicative of a loan amount, 

a second condition signal indicative of a periodic payment amount, and 
a third condition signal indicative of an interest rate. 

149. The apparatus of claim 148, wherein the second condition signal is 
indicative of a monthly payment amount. 



1 50. The apparatus of claim 148, wherein the offer signal further includes: 
20 a fourth condition signal indicative of a loan period. 

151. The apparatus of claim 137, wherein the offer signal includes 
a first condition signal indicative of a loan amount, 

a second condition signal indicative of a loan period, and 
25 a third condition signal indicative of an interest rate. 

152. The apparatus of claim 151, wherein the offer signal further includes: 
a fourth condition signal indicative of a periodic payment amount. 

30 j 53 The apparatus of claim 1 52, wherein the fourth condition signal is 

indicative of a monthly payment amount. 
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1 54. An apparatus for processing sales of items, comprising: 

a storage device; and 

a processor connected to the storage device, the borrower terminal and 
the at least one lender terminal, 

the storage device storing 

a program for controlling the processor; and 
the processor operative with the program to 

receive an offer signal including at least one condition signal, the offer 
signal defining an offer having at least one condition from a customer; 

receive a payment identifier signal for specifying an account from 
which funds may be paid; 

receive an informational signal relevant to the offer from a third 

party; 

store at least one rule signal from each of a plurality of sellers, 
each rule signal including at least one seller-defined restriction; 

compare the offer signal and the informational signal with at least 

one rule signal; and 

determine whether the at least one condition and the 
informational signal satisfy each seller-defined restriction of any rule. 

155. The apparatus of claim 154, wherein the processor is further operative 
with the program to: 

if a plurality of rules are satisfied, select one of the plurality of satisfied 

rules. 

156. The apparatus of claim 155, wherein the processor is further operative 
with the program to: 

select a random one of the plurality of satisfied rules. 

1 57. The apparatus of claim 1 55, wherein the processor is further operative 
with the program to: 
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ACCEPTANCE 
RATE 

2760 


h- 
CO 


CO 
r}- 




CPO , 








PUBLIC KEY 
2755 


12347AD73E 


35627A7C9 


1829CB612 


CONTACT 

2750 


SUE JOHNSON 


BILL JOHNSON 


JOHN 
WILLIAMSON 


ADDRESS 

2745 


25 MAIN STREEET, 
CHICAGO, IL 


102 45TH ST. 
NEW YORK, NY 


9492 6TH AVE. 
NEW YORK, NY 


AIRLINE NAME 


AMERICAN 


DELTA 


UNITED 
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VIA 

2875 


NON-STOP 


CHICAGO 


NON-STOP 


FLIGHT 
NUMBER 
2870 


1870 


CO 
CNJ 
CVJ 


S 

CO 


to 

CO 

UJ ™ 
1 

oc 
< 


AMERICAN 


AMERICAN 


UNITED 


TIME OF 
ARRIVAL 
2860 


6:00PM 


3:04PM 


7:10PM 


TIME OF 
DEPARTURE 
2855 


12:00PM 


7:00AM 


3:00PM 


o 

OO 
CNJ 


12/96 


11/97 








* — ' 

5 


i 


DESTINATION 
AIRPORT 

2845 


LOS ANGELES, CA 
(LAX) 


| LOS ANGELES, CA 
(LAX) 


SAN FRANCISCO, CA 
(SFO) 


ORIGINATING 
AIRPORT 

2J40 


NASHVILLE, TN 
(BNA) 


NEW YORK CITY 
(JFK). 


NEW YORK CITY 
(JFK) 
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CO 
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PASSENGER 
NAME 
RECORD 
NUMBER 

2995 


33333 






STATUS 
2990 


ACCEPTED 


PENDING 


PENDING 


OTHER 
RESTRICTIONS 

2985 




N/A 


N/A 


PRICE PER 
TICKET 

2980 


$547.01 


$188.00 


$200.00 


NUMBER OF 
PASSENGERS 
TRAVELING 

2975 


CO 




CM 


DATES OF 
RETURN 

2970 


4/29/97- 
4/30/97 


4/30/97 


4/30/97 


/ DATES OF 
' DEPARTURE 

I 2965 


\ 4/12/97- 
\ 4/14/97 


j 4/22/97 


J 4/22/97 
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CNJ 

CD 



WO 98/10361 



33/115 



PCT/US97/15492 





TUES- \ 
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TIME(S)0F 
DEPARTURE 
3022 
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11AM-2PM 


DATE(S) OF 
DEPTARTURE 
3020 


10/1/97- 
10/31/97 


4/1/97- 
5/31/97 


FLIGHT 
NUMBERS 
3018 


V/N 


V/N 


CONNECTION 
RESTRICTIONS 
3016 


N/A 


THRU 
CLEVELAND OR 
PITTSBURG 


DESTINATION 
CITY 
3014 


ORLANDO, FL 
(MCO) 


CHICAGO, IL 
(ORD) 
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CITY 

3012 
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(EWR) 


NEW YORK, 
NY (JFK) 


RULE 
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NUMBER OF 

SEATS 

AVAILABLE 

3068 




to 

CO 




DATE(S) 
3066 


4/29/97 


5/1/97 


5/1/97 


FLIGHT NO. 

3264 


249X 


1209 


CO 

o 
co 


AIRLINE 

3062 


AMERICAN 


AMERICAN 


AMERICAN 


RULE NUMBER 
3060 


234566 


234567 
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o 
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CO 
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MINIMUM PRICE 
3096 


LO 


$260 


CM 
CO 


DATE(S) 

3093 


5/2/97-5/13/97 


5/1/97-5/13/97 


5/1/97-5/31/97 


DESTINATION 
CITY 

3092 


NEW YORK, NY 
(JFK) 


LOS ANGELES, 
CA (LAX) 


CHICAGO, IL 
(ORD) 


ORIGINATING 
CITY 

3090 


CLEVELAND, 
OH (CLE) 


CLEVELAND, 
OH (CLE) 


NEW YORK, NY 
(JFK) 


AIRLINE 

3088 


AMERICAN 


AMERICAN 


AMERICAN 
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CO 
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RETURN I 


WITHIN 2 \ 
HOURS \ 




DATE(S) OF 
RETURN 

3135 


WITHIN 1 DAY 




TIME(S)OF 
DEPARTURE 

3130 


WITHIN 2 
HOURS 




DATE(S) OF 
DEPARTURE 

3125 


WITHIN 1 DAY 




RULE 
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3120 


45687 
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CO CO 



ADVANCE 

PURCHASE 

REQUIREMENTS 


WITHIN 2 DAYS 




MINIMUM 
PRICE 

3160 


WITHIN 
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INVENTORY 

RESTRICTION 
3350 


RETURN 
FRIDAY 


ONE STOP 


7 DAY RETURN 


INVENTORY 

PRICE 
3345 


$40.00 


$60.00 


$20.00 


INVENTORY 

RESTRICTION 
3340 


7 DAY RETURN 


RETURN 
FRIDAY 


ONE STOP 


INVENTORY 

PRICE 
3335 


$50.00 


$75.00 


$25.00 
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SEATS 
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eg 


CO 
CO 


CO 


CM 
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DATE 
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5/15/97 
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CO 
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O 
CM 
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CO 


ACTUAL 
QUANTITY 
SOLD 

3560 
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CO 
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FARE 
CLASS 

3555 


>- 


>- 


>- 






OFFERED 
PRICE 

3550 


o> 

co 
<& 




$329 


$409 


CJ> 

co 
«/> 


DESTINATION 
CITY 

3545 


LOS ANGELES 
(LAX) 


LOS ANGELES 
(LAX) 


LOS ANGELES 
(LAX) 


! LOS ANGELES 
(LAX) 


LOS ANGELES 
(LAX) 


ORIGINATING 
CITY 


NEW YORK 
(JFK) 


NEW YORK 
(JFK) 


NEW YORK 
(JFK) 


NEW YORK 
(JFK) 


NEW YORK 
(JFK) 


DEPARTURE 
DATE 

3535 


3/3/97 


3/3/97 


3/3/97 


3/3/97 


3/3/97 


FLIGHT NUMBER 
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CPO MANAGEMENT PROCESS 3600 ^) 



CUSTOMER OR TRAVEL AGENT ACCESSES CPO 
MANAGEMENT SYSTEM 3604 



RECEIVE CUSTOMER INFORMATION, ITINERARY. 
PRICE AND OTHER RESTRICTIONS FROM 
CUSTOMER OR TRAVEL AGENT 3608 



z 

CREATE RECORD OF CPO IN CPO DATABASE WITH 
RECEIVED INFORMATION AND STATUS "PENDING* 
3612 

^ 

DISPLAY LEGAL LANGUAGE AND AWAIT 
ACKNOWLEDGEMENT TO FORM CONDITIONAL 
PURCHASE OFFER (CPO) 3616 



EXTRACT PRICE FROM CPO DATABASE AND 
CUSTOMER INFORMATION FROM CUSTOMER 
DATABASE 3g 2 o 



4 

i 

TRANSMIT MERCHANT ID, BILLING DESCRIPTOR. 
TOTAL PURCHASE AMOUNT AND CREDIT CARD 

INFORMATION TO CREDIT CARD ISSUER FOR PRE- 
AUTHORIZATION 3624 




REQUEST 
ANOTHER 
CREDIT CARD 
FROM BUYER 

3632 



FIG. 36a 
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(a) FROM FIG. 36a 



EXECUTE EVALUATION PRXESS (FIG. 17) FOR EACH AIRLINE TO 
EVALUATE CPO AGAINST SECURED AIRLINES RULES DATABASE 

3640 




0^ 

TO FIG. 36c 

FIG. 36b 
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c J FROM FIG. 36b 




43/115 

d J FROM FIG. 36b 



EXTRACT RECEIVED 
INFORMATION FROM 
CUSTOMER AND CPO 

DATABASES AND 
RECEIVED INVENTORY/ 
FLIGHT INFORMATION 
TO CREATE 
PASSENGER NAME 
RECORD (PNR) 

3672 



I 



TRANSMIT (PNR) TO 
AIRLINE TO ESTABLISH 
RESERVATION 

3674 



TRANSMIT MERCHANT 
ID, BILLING 
DESCRIPTOR, 
PURCHASE AMOUNT 
AND CREDIT CARD 
INFORMATION TO 
CREDIT CARD ISSUER 

FOR PAYMENT 
36Z£ 



I 



UPDATE CPO 
DATABASE WITH PNR 

NUMBER AND 
SET STATUS TO 

"ACCEPTED" 
3gg2 



I 




e ) FROM FIG. 36b 



TRANSMIT REJECTION TO 
CUSTOMER 




TRANSMIT REJECTION TO 
AIRLINES MAKING 
COUNTEROFFER 

3696 



J. 



UPDATE CPO DATABASE 
STATUS TO "REJECTED" 

3694 



UPDATE CPO DATABASE 
STATUS TO "REJECTED" 

3698 



1 



£ 



EXECUTE AUDIT 
PROCESS (FIG. 18) FOR 
EACH AIRLINE 

3686 



c 



END 



3699 



FIG. 36c 
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EVALUATION PROCESS 
(CPO) 



3700 



EXTRACT ORIGINATING AND DESTINATION CITIES 
(O&D PAIR) FROM CPO RECORD 3705 



IDENTIFY ALL RULES PERTINENT TO EXTRACTED 
O&D PAIR 3J1fl 



FOR EACH IDENTIFIED RULE, COMPARE CUSTOMER RESTRICTIONS FROM FIELD 960 
THROUGH 995 OF CPO DATABASE WITH AIRLINE RESTRICTIONS FROM FIELDS 1016 



THROUGH 1044 OF SECURED AIRLINE RULES DATABASE 



3715 



TO FIG. 37b 




ACCESS CRS TO IDENTIFY FLIGHTS MEETING 
RESTRICTIONS OF SATISFIED RULE AND CPO AND 
HAVING SEATS AVAILABLE 3730 





FIG. 37a 



TO FIG. 37b 



TO FIG. 37b 
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FROM FIG. 
37a 



FROM FIG. 
37a 



FROM FIG. 
37a 



1 




SELECT FLIGHT WHICH MOST 
CLOSELY MATCHES CUSTOMER 
PREFERENCE OR MAXIMIZES 
CONVENIENCE 3740 






4 ; 


r 


SET RESPONSE TO "ACCEPT" 

3745 





IS CPO WITHIN 
AIRLINE SPECIFIED 
TOLERANCE FOR 
^GENERATING COUNTER 
OFFER? 

3750 



YES 



NO 



1 


r 


SET RESPONSE 


TO "REJECT" 




3755 



GENERATE A COUNTER OFFER 
WITH APPROPRIATE MODIFIED 
TERMS 

3760 



SET RESPONSE TO "COUNTER" 

3765 



RETURN (RESPONSE, FLIGHT NUMBER) 

3770 



FIG. 37b 
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AUDIT PROCESS 



1 
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DECREMENT INVENTORY IN 
SECURED AIRLINE RULES 
DATABASE, IF NECESSARY 

3810 


i 




CREATE RECORD IN AIRLINE AUDIT 
DATABASE 

3815 







FIG. 38 
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CPO RULE GENERATION PROCESS 



YES 



IS THE FLIGHT 
LIKELY TO DEPART WITH EMPTY 
SEATS? 
3910 



YES 



IS 

CURRENT INVENTORY 
ALLOCATION THE INITIAL 
ALLOCATION FOR 
THIS FLIGHT? 
3905 



NO 



ALLOCATE EMPTY SEATS TO SPECIAL 
FARE CLASS FOR CPO CUSTOMERS 

3915 



ESTABLISH APPROPRIATE MINIMUM 
FARE AND OTHER RESTRICTIONS TO 
STIMULATE SALES 3920 



UPDATE PRICING AND RESTRICTIONS, 
SEAT ALLOCATION AND FORECAST 
DATABASES 1300-1500 WITH NEW FARE 
CLASSES, ALLOCATED INVENTORY AND 

INITIAL PRICE AS APPROPRIATE 00 „ 

39Z5 



GENERATE CPO RULE CONTAINING 
ALLOCATED INVENTORY, ESTABLISHED 
MINIMUM PRICE AND OTHER 
RESTRICTIONS 3930 



TRANSMIT CPO RULE TO SECURED 
AIRLINE SERVER 3935 







FIG. 39 



c 



DOES 
DIFFERENCE 
BETWEEN FORECASTED 
ti AND ACUTAL DEMAND EXCEED 
NO\ PREDEFINED TOLERANCES 
FOR ANY FARE 
CLASS? 
3950 



YES 



±_Jt 

END 



ALLOCATE EXCESS CAPACITY FOR 
SALE TO CPO CUSTOMERS 395 



ESTABLISH APPROPRIATE MINIMUM 
FARE AND OTHER RESTRICTIONS TO 
STIMULATE SALES 3960 



UPDATE PRICING AND RESTRICTIONS, 
SEAT ALLOCATION AND FORECAST 
DATABASES 1300-1500 WITH 
ALLOCATED INVENTORY AND 
ESTABLISHED PRICE 3965 



I 



GENERATE CPO RULE CONTAINING 
ALLOCATED INVENTORY, ESTABLISHED 
MINIMUM PRICE AND OTHER 
RESTRICTIONS 3 g 70 



TRANSMIT CPO RULE 
AIRLINE SERVER 



TO SECURED 

3980 



3985 ** ) 
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o 

LU 

CO 
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o 

Q- 
O 



RESTRICTIONS / 
4060\ 


DO NOT WANT TO \ 
LEAVE U.S. \ 
TERRITORY \ 


WANT TO SEE 1 
BRITISH VIRGIN / 
ISLANDS / 


NO RESTRICTION^/ 


DESTINATION 
PORT 

4055 


NO CHOICE 


NO CHOICE 


NO CHOICE 


ORIGINATING 
PORT 

4050 


ST. THOMAS, 
USVI 


MIAMI, FL 


CANCUN, 
MEXICO 


COMPANION 
PASSENGERS 

4045 


MRS. JOHN 
DOE, JOHN 
DOE JR. 


ANN SMITH 


ANN SMITH 


CUSTOMER 
ID 

4040 


12345 


45231 


45231 


PRIMARY 

PASSENGER 

NAME 

4035 


JOHN DOE 


JAMES 
SMITH 


JAMES 
SMITH 


TRAVEL 
AGENT 
NUMBER 
4030 


4321 


2648 


2648 


m 


4/20/97 


4/21/97 


4/21/97 


CPO 
NUMBER 

4020 


23456 


23457 


23458 




4005^ 


4010^_ 





03 
O 

CD 
Li_ 
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Q 
LU 



O 

Lj7 ^ 

CO 

I 

o 

CL 

o 



STATUS 
4090 


ACCEPTED 


PENDING 


PENDING 


OTHER 
RESTRICTIONS 

4085 


LUXURY SIZE 
CABIN 


N/A 


LATE DINING/ 
KING CABIN 


PRICE PER 
TICKET 

4080 


$600.00 


$700.00 


$800.00 


NUMBER OF 
PASSENGERS 
TRAVELING 

4075 j 


CO 


CM 


CNJ 


DATES OF 
RETURN 

. 4070 


4/29/97- 
4/30/97 


4/30/97 


4/30/97 


/ DATES OF 
DEPARTURE 

4065 


\ 4/12/97- 
\ 4/14/97 


4/22/97 


J 4/22/97 



CD 
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o 
o 



LU 

1 

CD 

< 
Q 

GO 
LU 



cr 

LU 

cr 

ZD 

o 

LU 
CO 



LU 

DC 

p 5! 


TUES- \ 
THURS \ 


TUES. J 


TIME(S) OF 
DEPARTURE 
4122 


N/A 


11AM-2PM 


DATE(S) OF 
DEPTARTURE 
4120 


10/1/97- 
10/31/97 


4/1/97- 
5/31/97 


CRUISE 
NUMBERS 
4118 


N/A 


N/A 


ORIGINATING 
PORT 

4112 


ST. THOMAS 


ST. THOMAS 


RULE 
NUMBER 
4110 


45685 


45687 



C\J 

o 



LU 






ADVANCE PURCF 
REQUIREMENTS 


2 MONTHS 


1 MONTH 

l 


INVENTORY 
RESTRICTIONS OR 
AVAILABILITY mi 
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International application No. 
PCT/US97/I5492 



BOX II. OBSERVATIONS WHERE UNITY OF INVENTION WAS LACKING 
This; ISA found multiple inventions as follows;: 

This application contains the following inventions or groups of inventions which arc not so linked as to form a single 
inventive concept under PCT Rule 13.1. In order for all inventions to be searched, the appropriate additional search fees 
must be paid. 



Group 1. claims I- 51. 57-81, 84*, 96-123; 126-136 and 154-157, drawn to Methods and Devices for consummating 
binding contracts and for processing sales 

Group 2. claims 52-56. drawn to inventory allocation and revenue management 

Group 3, claims 82*, 83. 93-95: Drawn to Means to Deconstruct package into Components 

Group 4, claims 124-125. drawn to an Authentication Device 

Group 5. claims 137-153. drawn to Loan Processing 

• Claims 85-92 are grouped with independent claims 82-84 

Groups 1-5 arc related as subcombinations disclosed as usable together in a single combination. The subcombinations 
are distinct from each other if they arc shown to be separately usable. In the instant case, invention I has separate utility 
such as consummating a binding contract. Invention 2 has separate utility such as revenue management. Invention 3 has 
separate utility for determining which elements are within a package. Invention 4 has separate utility as a means for 
authenticating the validity of tickets, and Invention 5 has separate utility as a loan processor. 



l-'orm PCT/ISA/210 (extra shcciXJuly 1992)* 



WO 98/10361 



90/115 



PCT/US97/15492 



o 
eg 



LU 



col 

CO CNJ 

CO 7~ 

LU f ^* 1 

CC 

Q 

O 

< 



LU 

< 



CNJ 



UJ 

2: 

LU 
> 



< 
CD 



LU 
> 
< 



3 

cc 
o 

Q 
< 



o 



LU 



CC 
LU 

s 

X 



CC 
LU 
CO 
ZD 
X 

o 

CO 



o 

CO 



2> 



LU 



LU 

DC 
< 

CO O 
Q 
< 



O 

CO 



CD 
ll 



WO 98/10361 



91/115 



PCT/US97/15492 



o 

CO 

UJ 

_i 

CO 

< 
cc 



v^* 



o 

CO 
ZD 
O 



cvj 



UJ 

Q 
_i 
O 
X 

o 
cr 
< 



Eg- 



tr 

LU 

CD 

ZD 

Q 
CC 
< 
O 

t: 

Q 
UJ 

CC 
O 



oo 

CO 



<X5 
CO 



CO 
CO 
UJ 

cr 

Q 
Q 
< 



CO 



uj 2 
oo 

CO 
ZD 
O 



O 

GO 



CD 
CD 



OO 



CO 



< 

CO 
ID 
CO 



CN] 

o 



CVJ 
CVJ 
CVJ 
CVJ 

CVI 

CVJ 
CM 
CNJ 

CVJ 
CVJ 
CVJ 

cvi 

I 

CVI 
CVJ 
CVJ 
CVJ 



CO 
CO 
CO 
CO 

CO 
CO 

CO 

CO 



5 

I 



s 

z 

t— 
< 

tr- ~ 
LU 
LU 

cc 
I— 

CO 



< 



UJ 

> 
cr 
o 

o 

LU 

cc 



o 

< 

o 

: dc 
: O 



cc 
>— 

CO 



a 
o> 



i 

cc 
o 



CO 



2: 
o 



< 

— > 



o 



o 

CO 



CO 



o 

8 



s 



o 
o 



o 
o 



o 
CD 

Li_ 



WO 98/10361 



PCI7US97/15492 



92/115 




CD 

2= £ 
O 

CD ^ 
LU 

00 



o 

CO 



o 
o 



to 
o 
o 



o 
o 



CD _^ 

7 Z Ol 

^ O « 

• l — r-- 

— o 

CD UJ 

UJ GO 
CO 



o 
o 



lo 
O 
cd 



o 
o 



CO 
LO 



CO 
ID 

B 

CO 



in 



CD 
Z 
Q 

UJ 
CL 



UJ 

< 



o 

LU 

cr 

ft 

UJ 



UJ CO 



>- 
CO 



LLl 

CO 



>- 

ZD 
CO 



LU m 
co Hf 

g 5 



LO 
LO 



CO 



LO 



O ° 



co 



to" 



CM 



CO 

Lu O \£> 
^: ~ r-. 



s 

o 

LU 



C\J 

o 
o 

UJ 



o 
o 

LU 



Q DC W 
— UJ ^ 

SI 



o 
o 
o 



o 
o 
o 

CO 



o 
o 
o 



cr 

u_ o ^ 



CM 
CM 

CM 
O 



CO 

8 

o 



CO 




. S2. co 
^ ^ 



to to 



CO 
CO 



o 



CO 

S3 

o 



CO 



CO 

Q r: 



o 
cc 



< 



CO 
CO 



CD 
CD 

O 
O 
CO 
4S> 



cd 

CD 
CD 

to 

CM 



CD 

o 

CD 

o 

CD 



O 

o 

CD 
CD 
O 



CD 



UJ 

o 

CL LU 
Q_ 



to 

CO 



o 

CD 



LO 



O 
CD 

LO 
CM 



O 
CD 
CD 
LO 
CM 



CD 
CD 
CD 
O 
CM 
€0 



CD 



S Q N 
CO z 
UJ 



CO 

co 

CD 



CO 
OD 
CO 



CO 
OD 
OD 



Z CO 

o o p: 

H 2 
LU 



OD 
CO 
CO 



CD 
CM 
O 



CD 
CD 



O 
CD 



_ CM| 

O O 

lu 2: 

CO LU 



CO 
CO 
CO 



LO 
CD 
CD 



CD 
O 



O 
CD 



WO 98/10361 



93/115 



PCIYUS97/15492 



o 

CO 



CO 
< 



O 
< 
CO 



DATE / 

tickets i 
receivedV 

7188 \ 




PROCESSING 
FEE 

7187 


o 

CM 


SELLER 
AMOUNT 
AUTHORIZED 
7186 


$400 


BUYER 
AMOUNT 
CHARGED 
7185 


o 

CM 


TRANSACTION 
AMOUNT 

7184 


$380 


ACCEPTANCE 
DATE 

7183 


5/2/97 


OFFER ID 
7182 


0444 


TRANSACTION 
ID 

7181 


TR001 



Llj CO 



_ CO 



Si 



LU 

m 



UJ 



i cn 

<■ *- rr 

^ £ £ 

59 o i 




co o> 

CVJ CVJ 

lO IT) 

CD CD 
CD CD 



cn 

CD 
CO 



CO 
CD 



CD 

d 



WO 98/10361 



94/115 



PCTYUS97/15492 



o 

CNJ 

c\j 



< 
LU 

CO 



o 
o 



cvi 
o 



o 
o 



s 



CNJ 



O 
cc 



o 

CD 



O 

o 



o 
o 



o 
o 



CNJ 

r- 

UJ 
LU 

o 



CNJ 



O 

LU 
CO 



GC 
LU 
CD 



O 

o 



o 
o 



o 
o 



o 
o 



03 

CD 

Ll_ 



CM 



LU 

o 



CT5 

CD 
CD 



CD 
CO 



CD 

CO 



CO 
CO 



CNJ 



LU 



o 
o 



o 
o 

UJ 



o 
o 



o 
o 

LU 




WO 98/10361 



95/115 



PCI7US97/15492 



LU 

o 

I — o 

CO 

I — cvj 

2: ^ 

LU LU 



□_ 
LU 

cr 



CD 



2 
LU 



CVJl 



^ LU 
LU CD 

CL ^ 
LU 

cr 



o 

— p— 

cr 

LU 
>- 
ID 
CD 



cxi 

CO 

tuS" 



LU 



CO 
CM 

r- 



CO 

cm 

tin 
co 

CO 



CO 
CSJ 

CO 



o 
o 
o 



o 
o 
o 



CM 

CD- 



CO 
CO 



CO 
CO 



o 
o 

LU 



O 
O 
LU 



<7 

OJ CM 



WO 98/10361 



PCT/US97/15492 



c 



96/115 



TICKET BIDDING PROCESS 



3 



USER ESTABLISHES CONNECTION BETWEEN USER TERMINAL AND 
CENTRAL CONTROLLER 730Q 

* 



CENTRAL CONTROLLER REQUESTS CUSTOMER ID FROM 

USER 




YES 



USER PRESENTS CUSTOMER INFORMATDN 
INCLUDING NAME, ADDRESS, CREDIT CARD NUMBER, 
EXPIRATION DATE OF CREDIT CARD, AND FULL NAME 
OF CARDHOLDER 7306 

I 



USER TRANSMITS 
CUSTOMER ID TO CENTRAL 
CONTROLLER 

7312 



CENTRAL CONTROLLER CREATES RECORD OF 
CUSTOMER WITH RECIEVED CUSTOMER 

INFORMATION 7308 






CENTRAL CONTROLLE 
PREVIOUSLY ASSIGNED CU 
NEW CUSTOMER ID AND TR 
US 


R EITHER RETRIEVES 
STOMER ID OR ASSIGNS A 
ANSMITS CUSTOMER ID TO 
ER 7310 




)TOFIG.73b 



FIG. 73a 



WO 98/10361 



PCT/US97/15492 



97/115 
^\ FROM FIG. 73a 




f BEGIN OFFER SUBMISSION PROCESS } 

i 

CENTRAL CONTROLLER TRANSMITS GENERAL 
VENUE AND EVENT INFORMATION TO 

USER 7116 



USER/BUYER SELECTS DESIRED EVENT BASED ON 
THE EVENT ID NUMBER 731g 



I 



CENTRAL CONTROLLER REQUESTS SPECIFIC 
INFORMATION FROM USER ABOUT 

OFFER 7320 



CENTRAL CONTROLLER RECEIVES OFFER 
INFORMATION FROM USER 



7322 



CREATE RECORD OF OFFER WITH RECEIVED 
INFORMATION Jm 




DISPLAY LEGAL LANGUAGE AND 
AWAIT ACKNOWLEDGEMENT TO 
FORM GUARANTEED PURCHASE 
OFFER TO BUY 7330 



© 

FIG. 73b 



TO FIG. 73c 



L 



WO 98/10361 



PCTAJS97/15492 



98/115 

(c^FROM FIG. 73b 



CENTRAL CONTROLLER TRANSMITS 

USER INFORMAITON, TOTAL SALE 
AMOUNT AND SELLER'S CREDIT CARD 
INFORMATION TO CREDIT CARD 
ISSUER FOR PRE-AUTHORIZATION 

7332 



RECEIVE 
AUTHORIZATION CODE 
FROM CREDIT CARD 
ISSUER? 
7334 



YES 



REQUEST 
SEPERATE CREDIT 
CARD INFORMATION 
7336 



UPDATE OFFER AND 
TRANSACTION 
TABLES 7338 



END OFFER SUBMISSION 
PROCESS 



FIG. 73c 



WO 98/10361 



PCT/US97/15492 



99/115 



c 




FROM FIG. 
73a 



BEGIN OFFER REVIEW PROCESS 



J 



CENTRAL CONTROLLER TRANSMITS GENERAL 
VENUE AND EVENT INFORMATION TO 

USER 7340 



USER SELECTS DESIRED EVENT BASED ON EVENT 
ID NUMBER ?342 




USER TRANSMITS ORIGINAL TICKET 
NUMBER AND SEAT INFORMATION TO 
CENTRAL CONTROLLER 

7348 




TO FIG. 73e 



FIG. 73d 



WO 98/10361 



PCT/US97/15492 



100/115 




FROM FIG. 73d 



CENTRAL CONTROLLER TRANSMITS SEAT 
NUMBER AND ORIGINAL TICKET NUMBER TO 
VENUE CONTROLLER 7350 



VENUE CONTROLLER RETRIEVES RECORD FROM 
TICKET DATABASE MATCHING TICKET NUMBER 
TRANSMITTED BY CENTRAL CONTROLLER 

7352 



VENUE CONTROLLER VERIFIES THAT TICKET 



NUMBER MATCHES SEAT NUMBER 



7354 




VENUE CONTROLLER SENDS INVALID 
COMBINATION MESSAGE TO CENTRAL 
CONTROLLER ^ 



CENTRAL CONTROLLER TRANSMITS A 
MESSAGE TO USER INDICATING THAT 
THE TICKET NUMBER AND SEAT 
COMBINATION ARE INVALID 

7360 



USER RE-ENTERS TICKET INFORMATION 
AND TRANSMITS INFORMATION TO 
CENTRAL CONTROLLER 

7370 



TO FIG. 73 



FIG. 73e 



WO 98/10361 



PCT/US97/15492 



101/115 

E ) FROM FIG. 73e 




CENTRAL CONTROLLER DISPLAYS LEGAL LANGUAGE AND AWAITS 

ACKNOWLEGEMENT FROM USER 7372 



CENTRAL CONTROLLER TRANSMITS USER INFORMATION, TOTAL SALE AMOUNT 
AND SELLER'S CREDIT CARD INFORMATION TO CREDIT CARD ISSUER FOR PRE- ' 

AUTHORIZATION 

7374 



YES 



RECEIVE 
AUTHORIZATION CODE FROM 
CREDIT CARD ISSUER? 

7376 



NO 



UPDATE OFFER AND 
TRANSACTION 
TABLES 7380 



REQUEST ANOTHER CREDIT- 
CARD NUMBER 

7378 



ONCE ACKNOWLEDGEMENT HAS BEEN ACCEPTED FROM USER SELLING THE 
TICKET, CENTRAL CONTROLLER TRANSMITS NAME OF USER BUYING THE 
TICKET TO VENUE CONTROLLER m2 



VENUE CONTROLLER CREATES A NEW RECORD IN THE REPLACEMENT TICKET 
TABLE INDICATING NAME, ORIGINAL TICKET NUMBER AND SEAT NUMBER FIELDS 
' 7384 



VENUE CONTROLLER ASSIGNS NEW SEAT CODE, STORES CODE IN NEW SEAT 
CODE FIELD OF REPLACEMENT TICKET DATABASE AND TRANSMITS NUMBER TO 

CENTRAL CONTROLLER 73B6 




TOFIG.73g 



FIG. 73f 



WO 98/10361 



PCT/US97/15492 



102/115 

F ) FROM FIG. 73f 




CENTRAL CONTROLLER UPDATES THE NEW TICKET NUMBER FIELD OF THE 
TRANSACTION DATABASE WITH THE NEW SEAT CODE TRANSMITTED BY THE 

VENUE CONTROLLER 7388 



CENTRAL CONTROLLER CHARGES CREDIT CARD OF THE USER BUYING THE 
TICKET THE PRICE OF THE TICKET AND A PROCESSING FEE 7390 

i ~ 

NOTIFY USER SELLING THE TICKET THAT PAYMENT WILL BE TENDERED WHEN 
ORIGINAL TICKET HAS BEEN SURRENDERED 7 , QO 



CENTRAL CONTROLLER NOTIFIES USER BUYING THE TICKET THAT HIS 
GUARANTEED OFFER HAS BEEN ACCEPTED AND TRANSMITS 

THE TICKET CODE 7394 



I 



USER BUYING THE TICKET PRINTS TICKET CODE AND BRINGS TO VENUE TO 

GAIN ACCESS TO EVENT 73% 



CENTRAL CONTROLLER RECEIVES TICKETS AND CREDITS THE ACCOUNT OF 
THE USER SELLING THE TICKET THE PRICE OF THE TICKET(S) LESS A 

PROCESSING FEE 7398 



END OFFER REVIEW PROCESS 



FIG. 73g 



WO 98/10361 



103/115 



PCT/US97/15492 






CM) 










en 




UJ 




o 








UJ 




1 







WO 98/10361 



PCI7US97/15492 



104/115 
7530 



CENTRAL 
PROCESSING UNIT 



7531 



7532 



PROGRAM 






7533 



COLLATERAL 
DATABASE 



BORROWER 
DATABASE ZSM 



5 



LENDER 
DATABASE 7536 



3 



OFFER 
DATABASE Z53B 



I) 



CREDIT REPORT 
DATABASE 7540 



7542 Q 



RESPONSE 
DATABASE 7544 



3 



FIG. 75a 



WO 98/10361 



PCT/US97/15492 



105/115 
7560 

A. 



CENTRAL 
PROCESSING UNIT 



7561 




PROGRAM 






7533 



BORROWER 
DATABASE 



LENDER 
DATABASE 



OFFER 
DATABASE 



7534 



7536 



7538 



CREDIT REPORT 

DATABASE 2540 



COLLATERAL 
DATABASE 



7542 



RULES 
DATABASE 



7564 



FIG. 75b 



WO 98/10361 



105/115 



PCTYUS97/15492 




WO 98/10361 PCT/US97/15492 

107/115 



CO 



o 
o 

CO 



LU 
-2L 
O 
X 
Q. 
LU 
— I 
LU 



CO 
<J~> 



CO 
CO 
LU 

cr 
Q 
o 
< 



CO 



LU 



a 

LU 
Q 

LU 



cr 

LU 

Q 

LU 



CD 

to 
to 
to 



CO 

LU 
LU 

cr 
o 

CO 
CNJ 



< 

CO 



I 

5 



< 

CD 

o 



CO 
CM 

o 



co 

LU 

3 

CQ 
CO 

to 



CO 



1 



LU 

CO 

o 



co 



rr 7 

0> CD 



WO 98/10361 



108/115 



PCT/US97/15492 




WO 98/10361 



109/115 



PCIYUS97/15492 



CM 










m 










CJ> 




















DC 








O 








o 








CO 


CM 


co 


CO 


1— 






^J- 


o 

LU 








oc 








O 








o 










m 














































a. lu 
lu cr 


CM 


CM 


ay 


"1 


CO 


r- 


CD 




CO 




o 


Q UJ 








II 1 LJ 








OC ~~ 








o 
















oc t^l 








LU 








LL- 








LU 


CO 


CO 






CM 




CD 


Q 




CM 


CM 






CO 




OC 








LU 








t 








o 










CD 



WO 98/10361 



110/115 



PCTVUS97/15492 




WO 98/10361 



PCT/US97/15492 



111/115 



RESPONSE 
TIME 
6200 


1:00 


21:00 


RESPONSE 
DATE 
8198 


2/8/99 


3/2/99 


LOAN INTEREST 
RATE 

8196 




rsi 


LOAN TERM 
(YEARS) 
8194 


IT) 


O 
CO 


MONTHLY 
PAYMENT 
8192 


$1,000 


o 
in 

CO 


LOAN 
AMOUNT 
8190 


$100,000 


$70,000 


LENDER 
IDENTITY 
8188 


CITIBANK 


CHASE 


RESPONSE 
ID 
8186 


3333 


4444 


OFFER 
IDENTIFIER 
8184 


1123 


3278 




00 

CD 

LL_ 



O 

oo 



00 



CM 
OO 



WO 98/10361 



112/115 



PCT/US97/15492 



o 

SI 

ao 



CO 



o 
ac 
I— 

CO 
UJ 

cc 

UJ 



CD 



CO 



CM 

CO 



cc c 

LU t 



CVJ 



CC 
LU 



in 

CO 

A 



8 

CO 



< != 

o Q 
o LU 
o cc 

IS 

?5 



< 

Q 



CO 
A 



CO 
UJ 

cc 

UJ 



UJ 

CO 

< 

X 

a 



m 

CO 
CM 



O 
CO 
A 

UJ 
DC 
O 

_ o 
Q co 

< £ 

So 
UJ 
O CC 

— ~ a 

Q 

V 2 

I— < 
z: 

— \ 

Is 



§5 

co 

UJ 

cc 



< 

CO 

tc 
a 



o 

CD 
CO 



X3 
00 

CD 




CVJ 
CO 



CVJ 
CO 



WO 98/19361 



PCT/US97/15492 



■8230 



113/115 



RECEIVE CONDITIONAL PURCHASE OFFER 



8232 



RECEIVE PAYMENT IDENTIFIER 



8234 




REQUEST 
BORROWER TO RE- 
TRANSMIT 

8238 



RECEIVE INFORMATIONAL SIGNAL FROM THIRD PARTY 



8242 



TRANSMIT OFFER SIGNAL AND INFORMATIONAL SIGNAL TO 
LENDERS 

8244 



RECEIVE AT LEAST ONE ACCEPTANCE SIGNAL 

8246 




TO FIG. 82b 



FIG. 82a 



WO 98/10361 



PCT/US97/1S492 



114/115 
A 




SELECT ONE ACCEPTANCE SIGNAL 



8248 



IDENTIFY CORRESPONDING LENDER 



8250 




COLLECT PAYMENT 



NO 



< 



END 



8254 



FIG. 82b 



WO 98/10361 



PCI7US97/15492 



115/115 



RECEIVE CONDITIONAL PURCHASE OFFER 



•8260 



8262 



RECEIVE PAYMENT IDENTIFIER 



8264 




REQUEST 
BORROWER TO RE- 
TRANSMIT 

8268 

* 



RECEIVE INFORMATDNAL SIGNAL FROM THIRD 




PARTY 


8272 




STORE RULES FROM LENDERS 




8274 




COMPARE OFFER AND INFORMATIONAL SIGNALS WITH 


RULES 


8276 




NO 



IDENTIFY CORRESPONDING LENDER 



8280 




NO 



END 



COLLECT PAYMENT 



FIG. 82c 



8284 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US97/J5492 



A. CLASSIFICATION OF SUIUECT MATTER 
IPC(6) :G06F 17/60: H04L 9/00 

US CL :705/5, 6. 26. 28, 37, 38. 39, 44; 380/23, 24, 25, 49; 
According to International Patent Classification (IPC) or to both na tional classification and IPC 

B. FIELDS SEARCHED 

Minimum documentation searched (classification system followed by classification symbols) 

U.S. : 705/5, 6. 26. 28. 37, 38. 39, 44; 380/23. 24, 25, 49; 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and. where practicable, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


X,P 

X 
Y 

X 
Y 


US 5,557,518 A (ROSEN) 17 September 1996, see entire document. 

Laura Del Rosso "Marketel Says it Plans to Launch Air Fare 
'Auction' in June" Travel; Weekly, 29 April 1991, see entire 
document. 

US 4,799,156 A (SHAVIT et al.) 17 January 1989, see entire 
document. 


1-81, 84-92, 96- 

112, 

124-157 

1-51, 57-71, 73- 
86, 96-121, 
126-136, 
154-157 

52-56 

1-81, 84-92, 96- 
112, 124-136, 
154-157 

137-153 


[ X Further documents are listed in the continuation of Box C. | | See patent family annex. 


Speciil cmcgoriei of ched document!: *J* later document published after the international filinp dale or priority 

... , , r ■ • t t r . i • . ■ . d * 1 * * ,ui not in conflict with the application but cited to understand 
document defnung U.e general ..ate of U.e art wluch not cornered tf|- inej „ Qf „ under| ; invcn|)t)n 
to l»e of particular relevance ^ r* 

•E" enrlier document published nn or after the international Klin* dale * X " document of particular relevance; the claimed invention cammi l»c 

considered novel or cannot be considered In involve an inventive step 
"L" document which may throw doubts on priority claim(s) or which ti w,len * ne document is mken alone 
cited (o establish tJte publication time of another citation or other 

special reason <n specified) *Y* document of particular relevance; the claimed invention csnnoi be 

considered to involve an inventive step when the document is 
"»>• document referring to an oral disclosure, use. exhibition or other combined with one or more other such documents, inch combination 

being obvious to a person skilled in the art 

•P" document published prior to Uu uiternatkm.il Ming date bul l*l«r than . & . document member of the same patent fam.lv 
the priority dale claimed 7 


Date of the actual completion of the international search ' 
16 DECEMBER 1997 


Date of malbng of the international search report 

1 0 FEB 1998 


Name and mailing address of the ISA/US 
Com miss inner of Patents and Trademarks 

rk>x pci* 

Washington. D.C 20251 
I'acsimilc Nn. (703) 305-3230 


Authorized officer Q ) , * / /? 

V PINCHUS M.LAUFER / // 
Telephone No. (703) 306-4 1 77 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US97/I5492 



C (Continuation). DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



A 
X 



Y 
A 
A 

X.P 



US 4,903,201 A (WAGNER) 20 February 1990, see entire 
document. 



US 5,191,613 A (GRAZIANO et al.) 02 March 1993. 

US 5,021,953 A (WEBBER et al.) 04 June 1991, see entire 
document. 

US 5,262.941 A (SALADIN et al.) 16 November 1993, see entire 
document. 

US 5,404,291 A (KERR et al.) 04 April 1995, see entire document. 

US 5,361,199 A (SHOQUIST et al.) 01 November 1994. 

US 5,329,589 A (FRASER et al.) 12 July 1994. 

US 5,611,052 A (DYKSTRA et al.) II March 1997, see entire 
document. 



1-15, 18-20, 22- 
36, 64-70, 126, 
133, 135, 154,. 
and 155 

71-79 

52-56, 

82, 83, 85-95 
137-153 and 157 



52-56 

1-1 12, 126-157 
1-112. 126-157 
137-153 



Form I'CT/ISA/210 (continuation of second sheetXJuly I992>* 



INTERNATIONAL^. SEARCH REPORT 



4 



International application No. 
PCT/US97/I5492 



i^a I ^Ohacrvatinna wh w «"« ^und unsearchable (Continuation of item 1 of first sheet) 



This international report has not, been established in respect of certain claims under Article I7(2X&) for the following reasons: 

I. I~] Claims Nos::V ; K . 

because they relate to subject matter (not required to be searched by this Authority, namely: 



2. I I Claims Nos.: 

1 because they relate to parts of the international application that do not comply with the prescribed requirements to such 
an extent that no meaningful intemalional search can be earned out, specifically: 



3. £^ Claims Nos.: 

because they are dependent claims and arc not drafted in accordance with the second and third sentences of Rule 6.4(a). 



U»x II Observations where unity of invention is lacking (Continuation of item 2 of first sheet) 



This International Searching Authority found multiple inventions in this international application, as follows: 
Please See Extra Sheet. 



I . | x| As all required additional search fees were timely paid by the applicant, this international search report covers all searchable 



claims, 



2. | | As all searchable claims could be searched without effort justifying an additional fee* this Authority did not invite payment 

of any additional fee. 

3. | [ As only some of the required additional search fees were timely paid by the applicant, this international search report covers 

only those claims for which fees were paid, specifically claims Nos.: 



1 I No req ^ 4 ^|additional search fees were timely paid by the applicant. Consequently, this international search report in 
restricted I h ^!^cni^ first mentioned in Ihe claims; it is covered by claims Nos.: 



Remark on Protest 



I I Tllc additional search fees were accompanied by the applicant's protest. 
| | No protest accompanied the payment of additional search fees. 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



